[
https://issues.apache.org/jira/browse/CALCITE-6371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838299#comment-17838299
]
Mihai Budiu commented on CALCITE-6371:
--------------------------------------
Strictly speaking these are not literals, but expressions where all
subexpressions have compile-time constant values.
There is no literal representing 1/0.
People may introduce intentionally such expressions in the code, for example to
guard against incorrect input data. There is no "assert" in SQL, so this is one
way you could produce runtime errors.
On the other hand, a warning may be in order, but Calcite does not have any
mechanism for reporting warnings to the user. That would be something
worthwhile adding and using for this purpose. Coupled with a flag like -Wall
this could turn into the feature you are asking for.
> Add ability to configure RexExecutable behavior on exceptions
> -------------------------------------------------------------
>
> Key: CALCITE-6371
> URL: https://issues.apache.org/jira/browse/CALCITE-6371
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.36.0
> Reporter: Claude Brisson
> Priority: Major
>
> The current behavior of Calcite's {{RexExecutable}} constant folding class is
> to eat all exceptions encountered during reduction. The underlying reason, as
> far as I understand it, is that even if Calcite can't reduce an expression,
> maybe the evaluation engine will be able to do it. Fair enough.
> But it would be useful to be able to chose to let some exceptions go through.
> One good example is {{ArithmeticException}} errors. They occur on divisions
> by zero, negative logarithms, etc. and we may want to avoid the downstream
> evaluation engine to receive such invalid expressions.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
