[
https://issues.apache.org/jira/browse/CALCITE-5420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17644578#comment-17644578
]
Benchao Li commented on CALCITE-5420:
-------------------------------------
{quote}but maybe how the correlate id is being bound to the scope is not the
correct abstraction.
{quote}
I agree, currently most rules cannot handle {{RexSubQuery}} since we cannot
easily know it's correlation variable. If we put all the variables explicitly
in the {{{}RexSubQuery{}}}, this would make it easier while optimizing.
But this would be a big change, may be incompatible too. IMO, we'd better
introduce it as a configurable feature, and keep the current approach at the
same time. WDYT?
Also, for the old way, we should fix the corner cases as well. Maybe someday,
the new approach works well in all cases, and we can deprecate the old one
gradually.
> SqlToRel should populate projects corralate id for queries with aggregates.
> ---------------------------------------------------------------------------
>
> Key: CALCITE-5420
> URL: https://issues.apache.org/jira/browse/CALCITE-5420
> Project: Calcite
> Issue Type: Bug
> Reporter: James Starr
> Assignee: James Starr
> Priority: Major
>
> The following query does not populate correlate id in the project when
> SqlToRel.expand=false:
> {code:sql}
> SELECT SUM(
> (select char_length(dname) from "scott".dept where dept.deptno =
> emp.empno)) as s
> FROM "scott".emp
> {code}
> Having the correlate id populated is important for expanding nested queries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
