[
https://issues.apache.org/jira/browse/CALCITE-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
DongShengHe updated CALCITE-7825:
---------------------------------
Description:
This issue follows up on [vlsi's review
|https://github.com/apache/calcite/pull/5288#pullrequestreview-5313617214] and
[zzwqqq’s follow-up
comment|https://github.com/apache/calcite/pull/5288#issuecomment-5842156858] on
[PR 5288|https://github.com/apache/calcite/pull/5288].
RelMdTableReferences does not inspect RexSubQuery expressions in Project,
Filter, Join, or Calc. With expand=false, for example:
{code:java}
SELECT (SELECT MAX(sal) FROM emp) FROM dept
SELECT * FROM dept WHERE deptno IN (SELECT deptno FROM emp)
{code}
Both report only DEPT, omitting EMP.
RelMdTableReferences also has no Correlate handler. When a sub-query is
rewritten into a Correlate, getTableReferences returns null.
Update: Like Correlate, several other relational nodes have no dedicated
RelMdTableReferences handler and fall through to null, even though their table
references can be determined.
* Values should return an empty set. For example,
{code:java}
SELECT deptno FROM dept UNION ALL SELECT 5
{code}
currently returns null; it should report DEPT.
* Snapshot, Match, Collect, Uncollect, and Spool should propagate their
input's table references.
* RepeatUnion and Combine should merge their inputs' table references,
assigning distinct entity numbers to repeated references to the same table.
Since they have the same underlying cause, I think it makes sense to cover
these cases in this issue as well.
was:
This issue follows up on [vlsi's review
|https://github.com/apache/calcite/pull/5288#pullrequestreview-5313617214] and
[zzwqqq’s follow-up
comment|https://github.com/apache/calcite/pull/5288#issuecomment-5842156858] on
[PR 5288|https://github.com/apache/calcite/pull/5288].
RelMdTableReferences does not inspect RexSubQuery expressions in Project,
Filter, Join, or Calc. With expand=false, for example:
{code:java}
SELECT (SELECT MAX(sal) FROM emp) FROM dept
SELECT * FROM dept WHERE deptno IN (SELECT deptno FROM emp)
{code}
Both report only DEPT, omitting EMP.
RelMdTableReferences also has no Correlate handler. When a sub-query is
rewritten into a Correlate, getTableReferences returns null.
> RelMdTableReferences does not account for tables in RexSubQuery expressions
> or Correlate
> ----------------------------------------------------------------------------------------
>
> Key: CALCITE-7825
> URL: https://issues.apache.org/jira/browse/CALCITE-7825
> Project: Calcite
> Issue Type: Bug
> Reporter: DongShengHe
> Priority: Minor
>
> This issue follows up on [vlsi's review
> |https://github.com/apache/calcite/pull/5288#pullrequestreview-5313617214]
> and [zzwqqq’s follow-up
> comment|https://github.com/apache/calcite/pull/5288#issuecomment-5842156858]
> on [PR 5288|https://github.com/apache/calcite/pull/5288].
> RelMdTableReferences does not inspect RexSubQuery expressions in Project,
> Filter, Join, or Calc. With expand=false, for example:
> {code:java}
> SELECT (SELECT MAX(sal) FROM emp) FROM dept
> SELECT * FROM dept WHERE deptno IN (SELECT deptno FROM emp)
> {code}
> Both report only DEPT, omitting EMP.
> RelMdTableReferences also has no Correlate handler. When a sub-query is
> rewritten into a Correlate, getTableReferences returns null.
>
> Update: Like Correlate, several other relational nodes have no dedicated
> RelMdTableReferences handler and fall through to null, even though their
> table references can be determined.
> * Values should return an empty set. For example,
> {code:java}
> SELECT deptno FROM dept UNION ALL SELECT 5
> {code}
> currently returns null; it should report DEPT.
> * Snapshot, Match, Collect, Uncollect, and Spool should propagate their
> input's table references.
> * RepeatUnion and Combine should merge their inputs' table references,
> assigning distinct entity numbers to repeated references to the same table.
> Since they have the same underlying cause, I think it makes sense to cover
> these cases in this issue as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
