[CALCITE-7505] RelToSqlConverter fails to alias outer relation for correlated sub-queries in Filter

[Dwrite]

Jira Link
CALCITE-7505

This PR fixes incorrect SQL generation for correlated sub-queries in a Filter's WHERE clause.

The root cause is that Filter did not preserve the correlation variables it binds, so RelToSqlConverter could not reliably determine when the current node was the binding point of a correlation variable. As a result, correlation alias handling could be applied at the wrong level, leading to incorrect correlated references in generated SQL.

The fix adds variablesSet to Filter / LogicalFilter and only resets the correlation alias when the current Filter / Project actually binds the variable, the input row type matches, and the input is not a BiRel.

A follow-up change will cover similar correlated cases in Join conditions.

[mihaibudiu]

The JavaDoc above says: "a correlated variable defined by the given input"
Where is this check validating this fact?
(I am not sure how "defined by an input" is defined)

[Dwrite]

Sorry， that's my english fault, The wording is inaccurate. The method does not actually verify that the correlation variable is defined by the given input; it only checks for a correlated reference with a matching row type. I'll update the Javadoc to reflect what it actually does.

[mihaibudiu]

There can be many variables with the same type, please explain why your approach is correct.

[Dwrite]

Hi @mihaibudiu

Thanks for the question. During our test case execution, we observed that planner rules like FilterIntoJoinRule( test case with testFilterCorrelateMissingVariableCor) can reposition or push down a Filter. This optimization often causes the Filter's variablesSet to become stale, meaning the variable's rowType no longer matches the schema of the new underlying input.

Therefore, relying solely on correlIds.contains(v.id) is insufficient. We need the rowType equality check to ensure that this Filter remains the true binding point of the correlation variable post-optimization. If the types mismatch, it indicates the Filter has been relocated, and we should not trigger resetAliasForCorrelation.

Regarding the structure check, rather than a generic BiRel, I specifically restrict this validation to Join and LogicalCorrelate operators. These two operators represent the exact semantic boundaries where correlation aliases are defined and resolved. Checking for Join and LogicalCorrelate allows us to correctly determine whether the alias needs to be appended, ensuring correctness without interfering with other relational nodes.

Let me know if this clarifies the design choice!

[mihaibudiu]

It looks to me that you are describing a bug, I think having a wrong type on the correlated variables should be normally impossible - whoever rewrote the filter should have adjusted the variable types too. Am I wrong? If not, can you make sure that there is an issue filed for this?

Can a variable have the right type and also be obsolete at the same time?

Also, you can probably add an explanation here as a comment about why the type is needed.

[Dwrite]

You are correct, and I appreciate the sharp observation.

The rowType matching check is not a reliable discriminator. It was
introduced as an empirical workaround based on observed behavior in
specific test cases, not derived from a sound semantic invariant. As
you pointed out, a variable can have the correct type and still be
obsolete, so the check is not sound in general.

After mirroring the same variablesSet approach from Project to Filter,
all tests pass except for two cases that involve HepPlanner rules
(FilterIntoJoinRule-- testFilterCorrelateMissingVariableCor() and FilterCorrelateRule testFilterIntoJoinMissingVariableCor()
). I will investigate why
these two rules produce incorrect behavior and follow up.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
66.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud