Markus Klein

Hello @jorgecarleitao , thanks for your suggestion. Before going into design, I did have the same thought in the past. My thought back then had been, that I do not...

There is that, but currently I feel picking sensible defaults, requires more knowledge about what the user is trying to accomplish. It's by far not as straight forward as it...

Hi @baoyachi , don't have time for an elaborate answer right now. In the meantime though, maybe the documentation of `BufferDescription` is helpful: Cheers, Markus

Updated some documentation: * `BufferKind`: * `BufferDescription`: * `DataType`: I hope that would clarify things a little. Please tell me if it does. In short the difference is this: `DataType`...

> Declare that the 2GiB you mentioned above is not a varchar type, but a text type. It is intended as an example. PostgreSQL is not the only game in...

Long time since I contributed to turbodbc, but I feel there is no chance `turbodbc` is ever going support to JDBC as its sole purpose is to provide Python bindings...

Hello @leo-schick , I am missing something here. Sure the physical type for timstamps is `INT64`, but its logical type should be `TIMESTAMP`. There is even a test to prove...

Yeah, we should do that. I wonder however if this is not better fixed upstream in the `parquet` crate. Actually I assumed it would already do that. Maybe I am...

Hi @leo-schick , thanks again for your thorough Bug report. My current understanding is that by setting the logical type, the converted type should be implied. So I opened an...

It seems the missing converted type is due to `odbc2parquet` using `INT64` instead of `INT32` for Milliseconds precision timestamps. However switching to `INT32` the code now fails if setting the...