exposing the Calcite interfaces is going to be enough?
>> I'm quite sure. As for the specific method like
>> FlinkTypeFactory#toLogicalType, I think we think we can implement a simliar
>> type converter in Hive connector itself.
>>
>>
>> [1]
>> https://cwiki.apache.org/confluence/
fluence/display/FLINK/FLIP-216%3A++Introduce+pluggable+dialect+and+plan+for+migrate+Hive+dialect
>
> Best regards,
> Yuxia--
> 发件人：Martijn Visser
> 日 期：2022年03月31日 17:09:15
> 收件人：dev
> 抄 送：罗宇侠(莫辞)
> 主 题：Re: [D
ect+and+plan+for+migrate+Hive+dialect
Best regards,
Yuxia--
发件人：Martijn Visser
日 期：2022年03月31日 17:09:15
收件人：dev
抄 送：罗宇侠(莫辞)
主 题：Re: [DISCUSS] FLIP-216 Decouple Hive connector with Flink planner
Hi all,
Thanks for opening this discussion. I agree with Francesco that we should
go for the best so
Hi all,
Thanks for opening this discussion. I agree with Francesco that we should
go for the best solution instead of another bandaid or intermediate
solution. I think there's actually consensus for that, given the argument
provided by Yuxia:
> The first way is the ideal way and we should go in t
Sorry I replied on the wrong thread, i repost my answer here :)
As there was already a discussion in the doc, I'll just summarize my
opinions here on the proposed execution of this FLIP.
I think we should rather avoid exposing internal details, which I consider
Calcite to be part of, but rather r
