[
https://issues.apache.org/jira/browse/CALCITE-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828897#comment-15828897
]
Vineet Garg commented on CALCITE-1583:
--------------------------------------
Similar scalar query {code} select * from emps where deptno <> (select
count(deptno) from depts where depts.name = emps.name) {code} produces a plan
which doesn't take into account that rows for which {{depts.name = emps.name}}
doesn't match will still produce output since subquery expression is an
aggregate i.e. {{count}}. Note that such plan is generated in
{{SubqueryRemoveRule}} and {{Late Decorrelation}} path.
Similar example of IN query {code}select * from emps where deptno IN (select
count(deptno) from depts where depts.name = emps.name){code}
Let me see if I could write Calcite test cases with data.
> Wrong results for query with correlated subqueries with aggregate subquery
> expression
> -------------------------------------------------------------------------------------
>
> Key: CALCITE-1583
> URL: https://issues.apache.org/jira/browse/CALCITE-1583
> Project: Calcite
> Issue Type: Bug
> Reporter: Vineet Garg
> Assignee: Julian Hyde
> Labels: sub-query
>
> Following query produces wrong result:
> {code} select * from depts where exists (select sum(empno) from emps where
> depts.deptno = emps.deptno and 1=2) {code}
> Expected Result:
> {noformat}
> deptno | name
> --------+-----------
> 10 | Sales
> 20 | Marketing
> 30 | Accounts
> (3 rows)
> {noformat}
> Actual results
> {noformat} zero rows {noformat}
> Calcite rewrites such queries into JOIN which ignores the fact that aggregate
> functions such as {{sum}} always produce one row, effectively making
> {{EXISTS}} predicate always true.
> Same is the case with {{Scalar}} and {{IN}} sub-queries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
