Julian, would you be ok if we provided a contribution containing a configurable switch for string literal type?
Piotrek > On 6 Sep 2018, at 20:47, Piotr Nowojski <[email protected]> wrote: > > We know about this switch. Unfortunately it only solves/hides one of the > problems. > >> On 6 Sep 2018, at 20:02, Julian Hyde <[email protected]> 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 <[email protected]> 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 >> >
