[
https://issues.apache.org/jira/browse/CALCITE-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18107261#comment-18107261
]
Thomas Rebele commented on CALCITE-7264:
----------------------------------------
Adding an interface could be one way, though it is not extensible. E.g., it
would be nice to have the possibility to infer the safety of an expression
given its operators. An expression x/2 could be considered safe. An expression
x/y would not be considered safe, as it might evaluate to 1/0. If the API
separates these two, the RexSimplify can simplify more expressions.
[Julian's
comment|https://github.com/apache/calcite/pull/5184#issuecomment-5332030100] on
the PR for CALCITE-7722 made me wonder whether we could combine the inference
of safety with the inference of nullability. The definition of the operator is
responsible for defining the SqlReturnTypeInference. The SqlReturnTypeInference
could get a method getSafety which returns an enum SAFE, UNSAFE,
SAFETY_DEPENDS_ON_OPERANDS. In the case of the latter a method
inferSafety(SqlOperatorBinding opBinding) could return the safety.
(The safety of an expression could be seen as part of the type. Just
conceptually, but at some point it could become a part of RelDataType, similar
to how nullability is handled (by adding an "isSafe" method), if we decide this
is useful enough. Afaik, only the simplification uses the safety concept, so
adding safety to the type seems to not be worth the effort.)
> New API for determining if the evaluation of a RexNode may throw
> ----------------------------------------------------------------
>
> Key: CALCITE-7264
> URL: https://issues.apache.org/jira/browse/CALCITE-7264
> Project: Calcite
> Issue Type: New Feature
> Reporter: Thomas Rebele
> Priority: Major
>
> The SQL standard defines that 1/0 throws an exception. Calcite follows the
> standard here. However, some projects that use Calcite (e.g., Hive) define
> the result of 1/0 as NULL. This may lead to different results in RexSimplify:
> E.g., IS NULL(1/0) would throw for the SQL standard semantics, but would
> return TRUE for the Hive semantics.
> RexSimplify handles this with a concept called "safe" defined in
> [RexSimplify#isSafeExpression|https://github.com/apache/calcite/blob/34989b0ed7793cedf713c2f159de6247a730458c/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L1631].
> The safe operators are defined in
> [RexSimplify.SafeRexVisitor|https://github.com/apache/calcite/blob/34989b0ed7793cedf713c2f159de6247a730458c/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L1490].
> The goal of this ticket is to make the behavior configurable. The API would
> need to provide a method that accepts at least RexCall nodes. Maybe a more
> general approach is favorable, e.g., {{{}isSafeExpression(RexNode r){}}}.
> This ticket aims to provide a refinement of
> {{{}org.apache.calcite.sql.SqlOperator#isSafeOperator{}}}, which only takes
> the operator but not the arguments into account. To be discussed whether the
> new API replaces or supplements {{{}SqlOperator#isSafeOperator{}}}.
> The safeness information would be useful for other parts of the code as well,
> e.g., CALCITE-5315.
> See the related discussions:
> *
> https://issues.apache.org/jira/browse/CALCITE-7145?focusedCommentId=18016030#comment-18016030
> * [http://lists.apache.org/thread/cp7h28k1yfxv421q12y1wopbwgrzdzrx]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
