Dwrite commented on code in PR #4692:
URL: https://github.com/apache/calcite/pull/4692#discussion_r2647072350
##########
core/src/main/java/org/apache/calcite/sql/dialect/ClickHouseSqlDialect.java:
##########
@@ -404,4 +411,45 @@ private static void unparseFloor(SqlWriter writer, SqlCall
call) {
call.operand(0).unparse(writer, 0, 0);
writer.endList(frame);
}
+
+ @Override public boolean supportWrapNestedJoin(RelNode rel) {
Review Comment:
I have verified this against PostgreSQL, and as expected, PostgreSQL handles
nested join identifiers natively without requiring any subquery wrapping or
explicit aliasing. It can correctly resolve identifiers like d2.loc across
nested join boundaries.
This confirms that the issue is specific to certain dialects like
ClickHouse, which enforce stricter subquery isolation and scope boundaries. In
ClickHouse, the internal table qualifiers are effectively "hidden" from the
outer join scope unless they are flattened via an explicit AS alias in a
subquery.
By introducing dialect.shouldWrapNestedJoin(), we can keep the generated SQL
clean and standard for databases like PostgreSQL, while providing the necessary
"scoping fix" for dialects with these specific constraints.
--
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]
