[
https://issues.apache.org/jira/browse/CALCITE-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18047198#comment-18047198
]
Dmitry Sysolyatin commented on CALCITE-7340:
--------------------------------------------
In general, I agree that CorrelationId should be unique across a plan. This is
discussed in detail in the comments of [CALCITE-5390], and other people have
different ideas. I started to implement a visitor that normalizes the plan by
unifying CorrelationIds: https://github.com/apache/calcite/pull/4627. It tries
to keep the original CorrelationId as much as possible, but there is a problem
with JOIN ... ON. This is related to what [~dongsl] is talking about.
> it collects the CorrelationIds used by the node’s expressions. If an id
> belongs to the current scope, it will be added to the variablesSet property;
> otherwise, the variablesSet is empty, meaning the free variable belongs to an
> outer scope
I may not fully understand, but the problem is that the outer scope also does
not have this correlationId. For example, in [CALCITE-7286], there is a
`$cor0`, but it is not introduced anywhere.
> 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)
