[CALCITE-7505] RelToSqlConverter produces duplicate FROM aliases for correlated subqueries when hasImplicitTableAlias() is true#5036
Conversation
…correlated subqueries when hasImplicitTableAlias() is true
|
| /** Test case for | ||
| * <a href="https://issues.apache.org/jira/browse/CALCITE-7505">[CALCITE-7505] | ||
| * RelToSqlConverter produces duplicate FROM aliases for correlated subqueries</a>. */ | ||
| @Test void testExistsSubQueryAliasConflict() { |
There was a problem hiding this comment.
why is this using hasImplicitTableAlias()?
There was a problem hiding this comment.
Thanks for pointing this out — I’ve updated the PR description. The previous wording was inaccurate: this change is not really about hasImplicitTableAlias(). The actual issue is that Filter did not preserve the correlation variables it binds, so RelToSqlConverter could not correctly determine the binding scope for correlated references.
There was a problem hiding this comment.
Do you need to change the JIRA issue title and commit/PR message as well?
| } | ||
|
|
||
| @Override public Void visitCorrelVariable(RexCorrelVariable v) { | ||
| if (correlIds.contains(v.id) |
There was a problem hiding this comment.
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)
2 participants
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.