I have attached a reproducer testcase for my problem.
The problem is not in the planner itself but in the Sql to Rel conversion
https://issues.apache.org/jira/browse/CALCITE-3826
I am sorry I am not able to open Calcite with IntelliJ nor NetBeans.
I can push the producer to a github repo if you p
Il giorno mar 25 feb 2020 alle ore 14:43 Vladimir Sitnikov
ha scritto:
>
> >Does any ring bell ?
>
> Is it related to [CALCITE-3672] Support implicit type coercion for insert
> and update ?
> https://issues.apache.org/jira/browse/CALCITE-3672
> https://github.com/apache/calcite/pull/1720
Vladimi
>Does any ring bell ?
Is it related to [CALCITE-3672] Support implicit type coercion for insert
and update ?
https://issues.apache.org/jira/browse/CALCITE-3672
https://github.com/apache/calcite/pull/1720
>I am now trying to install IntelliJ, but it won't be so immediate
AFAIK it should be seamle
I have found another problem about EnumerableTableModify#getSourceExpressionList
It looks like it is not mapping correctly the expected datatypes of
bind variables in queries like UPDATE table set a=?,b=? where pk=?.
I am sorry I am not able to create easily a test case.
I see Calcite code switc
Danny,
We have found all of our showstoppers:
- We were not handling JoinInfo#nonEquiConditions (maybe it has been
added recently)
- EnumerableDefaults#nestedLoopJoinOptimized assumes that
AbstractEnumerable#asEnumerator returns an enumeration from the
beginning of the stream, this is fine, but our
