[
https://issues.apache.org/jira/browse/CALCITE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645019#comment-16645019
]
Vladimir Sitnikov commented on CALCITE-525:
-------------------------------------------
{quote} 2. Decorate the inner enumerables (Just like the PR does);
So I choose 2 in the PR/
{quote}
What is the practical use of the feature you implement? (I mean "exception
handler" feature)
As far as I can understand issue description, the issue is
a) linq4j optimizer is too optimistic and it causes certain queries fail "at
compile time" rather than at runtime. This should probably be addressed by
avoiding static expressions for "compile-time constants", or some other clever
technique.
It might be the case, we should start from reverting "static field"
optimization in linq4j.
In other words, I would suggest removing "static constant" optimization rather
than adding weird "exception handlers".
b) Error messages have little-to-no context. At best, runtime exceptions should
have pointer to the original SQL text, however runtime fails with obscure
"division by zero" or "NPE". However, the sad thing is Volcano Planner rules do
not propagate association of input SQL text with the resulting rel nodes, so
I'm not sure if there's a sane way to get "SQL line/position" for given
expression.
In other words, Volcano Planner does not propagate "debug information" to the
generated nodes/code.
However, I see absolutely no reason to have "ignore the error and continue
mode". It might easily produce invalid "executor state", and it might easily
result in "wrong data produced by SQL".
That is why I see absolutely no reason to have {{ExceptionHandler*}}
interfaces, enums, and so on. It just have absolutely no reason to exist as a
public API. On top of that, how {{ExceptionHandler*}} should behave for
{{Jdbc}}, {{Mongo}}, {{Elastic}} and other adapters? You can't add arbitrary
exception handlers in-between calc layer there.
However, I would not mind if the added interfaces are marked with
{{@Experemental}} since they could be removed at any point later.
/cc [~zhztheplayer]
> Exception-handling in built-in functions
> ----------------------------------------
>
> Key: CALCITE-525
> URL: https://issues.apache.org/jira/browse/CALCITE-525
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Hongze Zhang
> Priority: Major
>
> The standard calls for certain built-in functions to throw exceptions.
> Examples:
> * 1 / 0
> * MOD(1, 0)
> * OVERLAY('foo' PLACING 'x' FROM -1)
> * 'x' NOT LIKE 'x' ESCAPE 'x'
> First, these exceptions should occur at run time. They should cause the
> current value to become null, or the row to be omitted, but should not abort
> the query. (Actual behavior TBD.)
> Second, EnumerableCalc does constant reduction and generates code like
> 'static final int X = 0 / 0'. This code blows up when the class is loaded. It
> should not. The code should give errors for each row, as described above.
> While fixing this bug, see SqlOperatorBaseTest.testArgumentBounds and remove
> restrictions related to /, MOD and OVERLAY, LIKE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
