[
https://issues.apache.org/jira/browse/CALCITE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646168#comment-16646168
]
Vladimir Sitnikov commented on CALCITE-525:
-------------------------------------------
{quote}The row will be emitted, since the second input does not emit its
row.{quote}
I find that very disturbing, and I find lack of consistency a bad thing.
Consider
Q1)
{code:sql}select * from orders where order_id not in (1, 2, 0/0){quote}
Q2)
{code:sql}select * from orders o where order_id not in (select * from
values(1),(2),(0/0)){quote}
As you say, Q1 would return 0 rows, and Q2 would return all rows from orders
table, however the queries are pretty much "the same".
> 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)
