-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Coral-Trino] Support CROSS JOIN for Correlated Inner Queries #493
Conversation
* @param unnestSqlCall unnest sqlCall | ||
* @return true if the sqlCall is correlated to the outer query | ||
*/ | ||
private static boolean isUnnestSqlCallCorrelated(SqlCall unnestSqlCall) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this method be removed as it just calls isSqlCallCorrelation
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
modified
return true; | ||
private static boolean isSqlCallCorrelation(SqlCall sqlCall) { | ||
for (SqlNode operand : sqlCall.getOperandList()) { | ||
if (operand instanceof SqlIdentifier) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do we know for sure that any identifier operand of an unnest operator references a column from the base tables? Could it be a reference to a non-base table column?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all tables referenced can be seen as base tables.
|| (unnestOperand instanceof SqlCall | ||
&& ((SqlCall) unnestOperand).getOperator().getName().equalsIgnoreCase("transform")) | ||
|| (unnestOperand instanceof SqlCall | ||
&& ((SqlCall) unnestOperand).getOperator().getName().equalsIgnoreCase("if"))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the "if"
case here lost because we now recurse using isSqlCallCorrelation
into the operands of an "if"
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"if" is another SqlOperator. So now we recursively examine the operands of If
operator, if and when encountered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
…in#493) * [Coral-Trino] Enhancement to support CROSS JOIN for correlated inner query * remove isUnnestSqlCallCorrelated
…500) * [Coral-Trino] Enhancement to support CROSS JOIN for correlated inner query * remove isUnnestSqlCallCorrelated Co-authored-by: Aastha Agrrawal <[email protected]>
Prior to this PR, given an input hive SQL query like:
Coral generated an incorrect Trino SQL:
Since the unnest argument is correlated to the outer query, the expected Trino translation is:
The pre-existing logic in Coral was hard coded to recognize correlation based on specific patterns in the unnest argument. This PR generalizes that logic by recursively checking the unnest argument(s) to make that decision.
What changes are proposed in this pull request, and why are they necessary?
How was this patch tested?
./gradlew build
existing UTs pass + added a new UT + i-tested against production views.
tested for the previously failing production views