[
https://issues.apache.org/jira/browse/CALCITE-7145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18035383#comment-18035383
]
Thomas Rebele commented on CALCITE-7145:
----------------------------------------
We can improve the safeness by looking at the arguments. If we know that the
divisor is never 0, we can deduce that the operation is safe. There are some
test cases that rely on the simplifications that follow from that deduction.
I've prepared a [PR|https://github.com/apache/calcite/pull/4616] moving the
special handling of the DIVIDE operator to the code that determines its
safeness. The changes to RexSimplify#simplifyIsNull and
RexSimplify#simplifyIsNotNull are then quite general. While working on the PR I
discovered some errors in the existing RexProgramTest#testSimplifyDivideSafe
and fixed them.
However, now the DruidAdapter2IT#testComplexExpressionsIsNull fails, because it
fails to simplify {{{}( cast(null as INTEGER) + cast("city" as INTEGER)) IS
NULL{}}}. The evaluation of the expression in standard SQL could fail at the
cast at runtime because city is a VARCHAR and may contain a string that cannot
be casted to INTEGER. In Druid the result would be null, as far as I understand
[https://druid.apache.org/docs/latest/querying/sql-data-types#standard-types].
So CAST would be a safe operator in Druid, but a non-safe operator in Calcite.
There's SAFE_CAST in Calcite, but I couldn't find out how to configure
DruidAdapter2IT to use SAFE_CAST instead of CAST. How to achieve this?
> RexSimplify should not simplify IS NULL(10/0)
> ---------------------------------------------
>
> Key: CALCITE-7145
> URL: https://issues.apache.org/jira/browse/CALCITE-7145
> Project: Calcite
> Issue Type: Bug
> Reporter: Thomas Rebele
> Assignee: Thomas Rebele
> Priority: Major
> Labels: pull-request-available
>
> RexSimplify incorrectly simplifies {{IS NULL(10/0)}} to false and {{IS NOT
> NULL(10,0)}} to true
> In other DBMS it's either the inverse (sqlite, MySQL, MariaDB), or they throw
> an exception in both cases (Oracle, Postgres). The behavior was also
> mentioned in a comment on CALCITE-3368.
> Is it right that throwing an exception during query execution is the expected
> behavior according to the SQL standard?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
