Dwrite commented on code in PR #5036:
URL: https://github.com/apache/calcite/pull/5036#discussion_r3525101583
##########
core/src/main/java/org/apache/calcite/rel/rel2sql/RelToSqlConverter.java:
##########
@@ -547,9 +552,97 @@ public Result visit(Correlate e) {
return result(join, leftResult, rightResult);
}
+ /**
+ * Returns whether any expression (including nested sub-queries) references
a correlated variable
+ * defined by the given input and having the same row type.
+ */
+ private static boolean inputRowTypeMatchesCorrelVariable(
+ RelNode input,
+ Set<CorrelationId> correlIds,
+ Iterable<? extends RexNode> exprs) {
+
+ if (correlIds.isEmpty()) {
+ return false;
+ }
+
+ final RelDataType inputRowType = input.getRowType();
+
+ /** Visitor that detects matching correlated variables. */
+ class Finder extends RexVisitorImpl<Void> {
+ boolean found;
+
+ Finder() {
+ super(true);
+ }
+
+ @Override public Void visitCorrelVariable(RexCorrelVariable v) {
+ if (correlIds.contains(v.id)
Review Comment:
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
