We know about this switch. Unfortunately it only solves/hides one of the problems.
> On 6 Sep 2018, at 20:02, Julian Hyde <jh...@apache.org> wrote: > > Does https://issues.apache.org/jira/browse/CALCITE-2321 > <https://issues.apache.org/jira/browse/CALCITE-2321> help? > > >> On Sep 6, 2018, at 4:03 AM, Piotr Nowojski <pi...@data-artisans.com> wrote: >> >> Hi, >> >> We have small problem with CHAR type in Flink. Officially we do not support >> it and all input/output columns are of type VARCHAR. Because of that, nobody >> has ever thought about CHAR semantic (for example correctly handling padding >> in comparisons or other functions). However this collides with a teeny tiny >> problem that in Calcite string literals are of type CHAR. This leads to not >> so funny inconsistencies in queries and incorrect results. >> >> I wonder if we could provide a switch in Calcite to change the type of >> String literals to VARCHAR? I know that this is against the SQL standard, >> however quite a few databases are doing so for various reasons . One of them >> is that providing proper CHAR support can be tricky and nowadays it doesn’t >> provide much value to the user. I have seen quite often the pattern that >> some new db starts without CHAR support at all and add it only later (if >> ever). Providing such switch in Calcite would allow Calcite users do the >> same thing. >> >> I was thinking about alternative workaround - rewriting query plan and >> changing all of the CHAR types to VARCHAR on our side, but this seems like >> not that easy thing to do. But maybe I’m wrong and there is an easy way to >> do so on our side? >> >> Thanks, Piotrek >
