[
https://issues.apache.org/jira/browse/CALCITE-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18047165#comment-18047165
]
Mihai Budiu commented on CALCITE-7340:
--------------------------------------
I think we should keep the rules simple.
* Each separate correlation variable that appears in a plan should have a
unique name. There are no scopes for correlation ids.
* We can use a counter to generate fresh names. Could be based on a static, or
some other "global" data structure.
* We can write a visitor to collect all the names used within a plan in a set,
* We can write another visitor to rename correlation variables to fresh names
excluding the names in a given set.
* This will enable us to
** read serialized plans and
** combine multiple plans that use disjoint correlation ids into global plans
without conflicts.
* The rename visitor can be also used to rename correlation ids canonically,
so names are deterministic and do not depend on the order of execution of tests.
* This can also be used to check whether two plans are equivalent up to the
names of correlation variables
Happy to get feedback on these proposals. [~jensen] [~xiong] [~suibianwanwan33]
[~julianhyde] [~zabetak] [~dongsl] [~dmsysolyatin]
> 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)
