[
https://issues.apache.org/jira/browse/CALCITE-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18047251#comment-18047251
]
xiong duan edited comment on CALCITE-7340 at 12/24/25 2:00 AM:
---------------------------------------------------------------
I’ve reviewed part of the code. Currently, when converting {{SqlJoin}} to a
{{Join}} RelNode, we fail to extract outer references from correlated
subqueries within the join condition. This omission is precisely why {{$cor0}}
lacks a definition in CALCITE-7286.
Regarding the suggestion [~dongsl] to add an extra {{variablesSet}} parameter
representing the current references in the ON-clause correlated subquery within
the join scope: if the right node contains references that originate from the
left node of the join, then this join can be transformed into a
{{{}Correlate{}}}. However, it must be clarified whether, during this
transformation, the references from correlated subqueries in the ON clause are
properly extracted. If {{Correlate}} can indeed reference all variables in the
{{{}variablesSet{}}}, then there should be no issue. Later, when converting
back to a {{Join}} RelNode, we can simply extract the correct references from
the ON condition and use them as the {{{}variablesSet{}}}, without needing
additional parameters for differentiation(This is what is currently missing).
Finally, we should not introduce a new {{variablesSet}} in {{RelFieldTrimmer}}
to patch an incomplete plan. The plan should already be complete before
{{RelFieldTrimmer}} runs—meaning it should be directly reversible back to valid
SQL. This completeness likely constitutes a key criterion for evaluating the
fix for CALCITE-7274.
was (Author: nobigo):
I’ve reviewed part of the code. Currently, when converting {{SqlJoin}} to a
{{Join}} RelNode, we fail to extract outer references from correlated
subqueries within the join condition. This omission is precisely why {{$cor0}}
lacks a definition in CALCITE-7286.
Regarding the suggestion [~dongsl] to add an extra {{variablesSet}} parameter
representing the current references in the ON-clause correlated subquery within
the join scope: if the right node contains references that originate from the
left node of the join, then this join can be transformed into a
{{{}Correlate{}}}. However, it must be clarified whether, during this
transformation, the references from correlated subqueries in the ON clause are
properly extracted. If {{Correlate}} can indeed reference all variables in the
{{{}variablesSet{}}}, then there should be no issue. Later, when converting
back to a {{Join}} RelNode, we can simply extract the correct references from
the ON condition and use them as the {{{}variablesSet{}}}, without needing
additional parameters for differentiation(This is what is currently missing).
Finally, we should not introduce a new {{variablesSet}} in {{RelFieldTrimmer}}
to patch an incomplete plan. The plan should already be complete before
{{RelFieldTrimmer}} runs—meaning it should be directly reversible back to valid
SQL. This completeness likely constitutes a key criterion for evaluating the
fix for CALCITE-7242.
> The rules governing the use of CorrelationId values in plans are not fully
> specified
> ------------------------------------------------------------------------------------
>
> Key: CALCITE-7340
> URL: https://issues.apache.org/jira/browse/CALCITE-7340
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.41.0
> Reporter: Mihai Budiu
> Priority: Minor
>
> This issue is really about the Calcite internal representation of Rel nodes.
> There have been several recent discussions about manipulating plans that
> contain CorrelationId values, and the conclusion seems to be that the rules
> governing the use of such variables is not clear.
> Ideally these rules should be spelled out in a specification, and there
> should be a tool to enforce them by validating plans. The JavaDoc for this
> tool may be the right place to write the specification. I don't expect that
> the specification will be long or complicated.
> RelBuilder may not be the right place to enforce such rules, because it
> usually does not have visibility over the entire plan, and some of these
> rules have to apply globally over entire plans.
> See CALCITE-5784, CALCITE-7045 and the discussion in github over CALCITE-7336
> for examples.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
