Hi Sergey,

There is a discussion[1] for this FLIP before.

I like this feature, thanks for driving this. I hope it does not need to
much customization (if there is any improvement which would benefit both
Calcite and Flink, it would be great to push those also to upstream
project, and I would like to help on that)

[1] https://lists.apache.org/thread/mglop6mgd36rrbjt7ojyd5sj8tyoc3c2

Sergey Nuyanzin <snuyan...@gmail.com> 于2023年7月19日周三 06:18写道:

> Hello everyone
>
> I'd like to revive FLIP-154[1] a bit.
>
> I failed with finding any discussion/vote thread about it (please point me
> to that if it is present somewhere)
>
> Also FLIP itself looks abandoned (no activity for a couple of years),
> however it seems to be useful.
>
> I did a bit investigation about that
>
> From one side Calcite provides its own coercion... However, sometimes it
> behaves strangely and is not ready to use in Flink.
> for instance
> 1) it can not handle cases with `with` subqueries and fails with NPE (even
> if it's fixed it will come not earlier than with 1.36.0)
> 2) under the hood it uses hardcoded `cast`, especially it is an issue for
> equals where `cast` is invoked without fallback to `null`. In addition it
> tries to cast `string` to `date`. All this leads to failure for such
> queries like `select uuid() = null;` where it tries to cast the result of
> `uuid()` to date without a fallback option.
>
> The good thing is that Calcite also provides a custom TypeCoercionFactory
> which could be used during coercion (in case it is enabled). This could
> allow for instance to use `try_cast` instead of `cast`, embed the fix for
> aforementioned NPE, enable only required coercion rules. Also it will
> enable coercions rule by rule instead of big bang.
>
> I would volunteer to update the FLIP page with usage of a custom factory if
> there are no objections and come back with a discussion thread to revive
> the work on it.
>
> [1]
>
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-154%3A+SQL+Implicit+Type+Coercion
> --
> Best regards,
> Sergey
>


-- 

Best,
Benchao Li

Reply via email to