Markus Klein

Hello @leo-schick , `odbc2parquet 0.13.0` has been released. It uses instant semantics, if the database is "Microsoft SQL Server" and the relational type is `DATETIMEOFFSET`. I'll leave this issue open...

Tests with Postgres have shown, that to an ODBC client both `TIMESTAMP` and `TIMESTAMPTZ` are just presented as ODBC type `TIMESTAMP`. However, Postgres seems to return the timestamp as UTC...

In my tests it seems that Postgres does convert the timestamp to UTC. It is just that from the client side I have no way of telling wether this is...

@leo-schick Almost forgot to ask. Does the tool work for you now?

Hello Adrian, There are a whole bunch of things which can improve here. I use this incident as a trigger to write them all down. This scenario is not so...

Damn, I already wrote a test for this scenario. https://github.com/pacman82/odbc2parquet/blob/3309f5d4017430c9b99dd68991bdd15852256b19/tests/lib.rs#L356 Sadly it is currently only ever executed on Linux so I did not catch the UTF-16 encoding issue. Oh, well...

Version `0.6.4` is releasing with improved warnings and enables them by default. This should have at least saved you some time debugging the issue.

Hi @AdrianSkierniewski, yes I am unsure about the log level (info or warn? Suggestions?), but I want to make it visible which mode the tool is in, since the row...

Thanks @AdrianSkierniewski I'll take your advice and will log it as a warning. Cheers, Markus

Hi, thanks for the benchmark. I would also be interessted in the overhead of the iterator in the two pass scenario. I.e. there we iterate twice to avoid allocations.