Skip to content

[CALCITE-7753] CorrelateProjectExtractor corrupts plans with nested Correlates that reuse the same correlation id - #5231

Open
snuyanzin wants to merge 1 commit into
apache:mainfrom
snuyanzin:calcite7753
Open

[CALCITE-7753] CorrelateProjectExtractor corrupts plans with nested Correlates that reuse the same correlation id#5231
snuyanzin wants to merge 1 commit into
apache:mainfrom
snuyanzin:calcite7753

Conversation

@snuyanzin

@snuyanzin snuyanzin commented Aug 29, 2026

Copy link
Copy Markdown
Contributor

Jira Link

CALCITE-7753

Changes Proposed

The change to fix CorrelateProjectExtractor for downstream projects

… Correlates that reuse the same correlation id
* <a href="https://issues.apache.org/jira/browse/CALCITE-7753">[CALCITE-7753]
* CorrelateProjectExtractor corrupts plans with nested Correlates that reuse
* the same correlation id</a>. */
@Test void testNestedCorrelatesSharingCorrelationId() {

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in jira: it is not reproducible with pure SQL in Calcite

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the bug requires two nested Correlates that share the same correlation id, and pure SQL (in Calcite) never produces that shape: Calcite's SqlToRelConverter gives every correlated subquery scope its own id.

@sonarqubecloud

Copy link
Copy Markdown

@mihaibudiu

Copy link
Copy Markdown
Contributor

I left a comment related to this in Jira questioning whether this fix belongs in Calcite.

@mihaibudiu mihaibudiu left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the change is "safe", although the plan it rejects may be illegal.
But in general I don't think rules can guard against any possible kind of adversarial incorrect plan.

Comment on lines +120 to +121
boolean rightRebindsCorrelationId =
rebindsCorrelationId(right, correlate.getCorrelationId());

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering if its possible to plug the fix in findCorrelationDependentCalls to avoid traversing again a potentially large sub plan? How about stopping traversal inside findCorrelationDependentCalls if we encounter a correlate with the same id?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants