dssysolyatin commented on code in PR #4692:
URL: https://github.com/apache/calcite/pull/4692#discussion_r2638981347
##########
core/src/main/java/org/apache/calcite/rel/rel2sql/RelToSqlConverter.java:
##########
@@ -223,6 +223,73 @@ private static class AliasReplacementShuttle extends
SqlShuttle {
}
}
+ /**
+ * Wraps a nested join into a subquery with explicit column aliases.
+ *
+ * <p>This is specifically required for dialects like ClickHouse where the
+ * identifier resolver cannot resolve columns with internal table qualifiers
+ * (e.g., 'd1.loc') when they are wrapped in a subquery alias. By forcing
+ * an explicit 'AS' projection for every column, we ensure the identifiers
+ * are flattened and visible to the outer query block.
+ *
+ * @param input The Result of the nested join branch
+ * @param inputRel The RelNode representing the join branch to extract row
types
+ * @param outerAlias The alias to be assigned to the wrapped subquery
+ * @return A new Result containing the wrapped SQL with explicit aliases
+ */
+ protected Result wrapNestedJoin(Result input, RelNode inputRel, String
outerAlias) {
+ final SqlParserPos pos = SqlParserPos.ZERO;
+
+ // Extract the underlying SqlSelect from the input Result.
+ // We manipulate the Select node directly to avoid redundant nesting
+ // often introduced by Result.asSelect().
+ final SqlSelect innerSelect = (SqlSelect) input.asSelect();
+ final SqlNodeList originalSelectList = innerSelect.getSelectList();
+ final List<String> fieldNames = inputRel.getRowType().getFieldNames();
+
+ final List<SqlNode> newSelectList = new ArrayList<>();
+
+ // Iterate through the fields to build explicit projections.
+ // Example: transforms 'd1.deptno' into 'd1.deptno AS deptno'.
+ for (int i = 0; i < fieldNames.size(); i++) {
+ SqlNode expr = originalSelectList.get(i);
+ String targetName = fieldNames.get(i);
+
+ // If the expression is already aliased, strip the AS to get the raw
expression.
+ if (expr.getKind() == SqlKind.AS) {
Review Comment:
It is quite strange. What if there are ambiguous fields?
What will happen if I want to have something like `t1.id as customer_id,
t2.id as product_id`?
It will become `t1.id as id`, `t2.id as id`
Also, can you point me to ClickHouse documentation that shows this
limitation?
Have you tried creating an issue in the ClickHouse repository as well ?
##########
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:
Why dialect itself detect if join is nested ? Why dialect just don't have:
```
boolean supportWrapNestedJoin() {
return true // just true for clickhouse without logic
}
```
Similar to `requiresAliasForFromItems`
Then `RelToSqlConverter` detect whether the join is nested or not, instead
of moving such logic on dialect level
--
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]
