Thanks! We will look into it. If we decide to go this path we will create a 
JIRA ticket for this.

Piotrek

> On 10 Sep 2018, at 19:12, Julian Hyde <jh...@apache.org> wrote:
> 
> 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
>>>> 
>>> 
>> 
> 

Reply via email to