mihaibudiu commented on code in PR #4692:
URL: https://github.com/apache/calcite/pull/4692#discussion_r2648531610
##########
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:
Significantly lower != 0.
A compiler has to work for all user programs.
The worst case is that some programs are compiled to produce incorrect
results. These kinds of bugs are also very hard to diagnose when they happen.
So why not avoid them?
I can easily see a program that has many tables named T0, T1, etc. where
such a collision can happen.
For column names Calcite automatically generates fresh names if there is a
collision.
If that's not true for relation names (I don't know myself), I think the
implementation has to make the extra effort to generate correct code, for
example by computing the used names before generating a fresh identifier. If
uniquify does what you need, why not use it?
--
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]
