Dwrite commented on code in PR #4692:
URL: https://github.com/apache/calcite/pull/4692#discussion_r2637132295
##########
core/src/main/java/org/apache/calcite/sql/dialect/ClickHouseSqlDialect.java:
##########
@@ -404,4 +411,37 @@ private static void unparseFloor(SqlWriter writer, SqlCall
call) {
call.operand(0).unparse(writer, 0, 0);
writer.endList(frame);
}
+
+ @Override public boolean mustWrapNestedJoin(RelNode rel) {
+ if (!(rel instanceof Join)) {
+ return false;
+ }
+ Join join = (Join) rel;
+
+ // ClickHouse primarily requires wrapping the right side of a JOIN
+ // when it contains a nested JOIN
+ return containsJoinRecursive(join.getRight());
+ }
+
+ /**
+ * Recursively checks if a RelNode contains a JOIN, looking through
+ * transparent single-input operators.
+ */
+ private static boolean containsJoinRecursive(RelNode rel) {
Review Comment:
Good question.
A visitor would indeed be the right tool if we needed a full or deep
traversal
of the relational tree. In this case, however, we intentionally keep the
check
shallow.
For ClickHouse, the restriction only applies when a JOIN appears directly as
the right (or in some cases left) input of another JOIN, possibly wrapped by
a
small number of transparent operators (e.g. Project / Filter / Sort).
We do not want to detect JOINs arbitrarily deep in the subtree.
Using a visitor here would traverse deeper than necessary and could lead to
over-wrapping in cases where the nested JOIN is not syntactically exposed at
the
JOIN boundary.
For this reason, a small structural check is used instead of a general
visitor.
I’ve added comments to clarify this intent.
--
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]
