Dwrite commented on code in PR #4692:
URL: https://github.com/apache/calcite/pull/4692#discussion_r2647071749
##########
core/src/main/java/org/apache/calcite/rel/rel2sql/RelToSqlConverter.java:
##########
@@ -233,7 +300,13 @@ public Result visit(Join e) {
break;
}
final Result leftResult = visitInput(e, 0).resetAlias();
- final Result rightResult = visitInput(e, 1).resetAlias();
+ Result rightResult = visitInput(e, 1).resetAlias();
+
+ if (dialect.shouldWrapNestedJoin(e)) {
+ String newAlias = "t" + e.getId(); // alias
Review Comment:
Regarding the safety of the identifier t + e.getId():
In the RelToSqlConverter phase, original SQL aliases (like 'j') are often
not preserved or can become ambiguous after multiple logical transformations.
Using rel.getId() is a standard practice in Calcite for generating synthetic
aliases because:
Global Uniqueness: RelNode IDs are globally unique within a single planning
session. This ensures that the generated alias t{id} will not collide with any
other synthetic aliases generated by the converter for different nodes in the
same query tree.
Deterministic Scoping: Since we are creating a new subquery scope to resolve
the ClickHouse scoping issue, this unique identifier provides a clean boundary.
Even if a user-defined table named t123 exists, the risk of collision is
significantly lower than attempting to reuse or guess original aliases which
might have been pruned or renamed by optimization rules.
Avoids Identifier Shadowing: By forcing this unique alias at the join
boundary, we ensure that the outer scope has a deterministic way to reference
the flattened columns without worrying about shadowing identifiers from deeper
nested structures.
While using SqlValidatorUtil.uniquify is another option, it requires
maintaining a usedNames set across the entire implementation. Given Calcite's
internal conventions, t + id provides the best balance between implementation
robustness and identifier safety for this dialect-specific fix.
--
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]
