Yes, as long as it is fully tested and documented. This is not a one line fix. It’s quite a major feature, and if it’s not done properly Calcite will be picking up the pieces for years.
Julian > On Sep 10, 2018, at 1:26 AM, Piotr Nowojski <pi...@data-artisans.com> wrote: > > 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 <pi...@data-artisans.com> wrote: >> >> 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 >>> >> >
