Soma Mondal created CALCITE-3318:
Summary: Preserving CAST of STRING operands in comparison operator
Key: CALCITE-3318
URL: https://issues.apache.org/jira/browse/CALCITE-3318
Project: Calcite
This is kind of in the scope of implicit type coercion which is supported in
CALCITE-2302.
For sql dialect that does not support implicit type coercion, strip explicit
cast is a mistake.
I think this can be seen as a bug and we should log an issue to fix. But just
like you said, if we support
Hi Julian,
After some further analysis, it seems that the mandatory cast is only
required in SOME cases for BigQuery.
Please see attached my analysis for Hive, MySQL, Netezza and Oracle.
https://drive.google.com/open?id=1GJ_VuDY7GQS-aPbWf4EKj73dYCqaRaEqPTjmXLkPW_g
I'm thinking of having the
I might be mistaken, but disabling stripCastFromString() for some dialects and
not others doesn’t sound like it’s solving the root cause of the problem.
Julian
> On Aug 26, 2019, at 7:49 AM, Soma Mondal wrote:
>
> Hi Julian,
>
> 2 tests failed when I made the stripCastFromString() no-op.
>
Hi Julian,
2 tests failed when I made the stripCastFromString() no-op.
1.
testDb2DialectSelectQueryWithGroup
2.
testSelectQueryWithGroup
Above tests pretty much do the same thing and basically strip the cast from
String literal something like this:
Expected:
SELECT COUNT(*),
I guess you’re talking about the JDBC adapter, and generating SQL for other
dialects.
I don’t recall why we have stripCastFromString() but I know that it was
introduced for a good reason. Try making it no-op and see which tests fail.
Julian
> On Aug 23, 2019, at 3:32 AM, Soma Mondal wrote:
Hello,
We have a REL which has this information
select * from employee where employee_id = cast('12' as float);
but Calcite removes the CAST from the STRING literal('12' in our case).
select * from employee where employee_id = '12';
There are dialects which needs explicit casting in the above
