[
https://issues.apache.org/jira/browse/CALCITE-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18093846#comment-18093846
]
zzwqqq commented on CALCITE-7642:
---------------------------------
Yeah, thanks for checking that, the top-level SELECT examples work in pg. But
if the generated SQL is used as a derived table, the duplicate output names can
cause a failure: [https://onecompiler.com/postgresql/44ub6d7xe]
That said, I may still be mixing two different things here, and the PostgreSQL
runtime behavior may not be the main point.
What I was trying to raise is about RelToSqlConverter's output-name contract.
Current behavior:
* rowType field names: id, ID
* dialect.isCaseSensitive(): false
* generated SQL output names: "id", "ID"
For that dialect setting, "id" and "ID" are duplicates according to the
dialect's name matching rule. But RelToSqlConverter currently emits both names
unchanged.
So I think the real question is: should RelToSqlConverter keep generated output
field names unique according to dialect.isCaseSensitive()?
> RelToSqlConverter may generate duplicate output column names for
> case-insensitive dialects
> ------------------------------------------------------------------------------------------
>
> Key: CALCITE-7642
> URL: https://issues.apache.org/jira/browse/CALCITE-7642
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: zzwqqq
> Assignee: zzwqqq
> Priority: Major
> Labels: pull-request-available
>
> RelToSqlConverter can emit output column names that are distinct in a row
> type but not distinct for the target dialect.
> Reproducer:
> Use a case-insensitive PostgreSQL dialect:
> {code:java}
> new PostgresqlSqlDialect(
> PostgresqlSqlDialect.DEFAULT_CONTEXT.withCaseSensitive(false)){code}
> Input SQL:
> {code:sql}
> SELECT *
> FROM (VALUES (1)) AS "t" ("id")
> JOIN (VALUES (1)) AS "t0" ("ID") ON TRUE
>
> {code}
> Current output:
> {code:java}
> SELECT "t"."id", "t0"."ID"
> FROM (VALUES (1)) AS "t" ("id"),
> (VALUES (1)) AS "t0" ("ID"){code}
> The output column names are "id" and "ID", which are duplicates for a
> case-insensitive dialect.
> Expected output:
> {code:sql}
> SELECT "t"."id", "t0"."ID" AS "ID0"
> FROM (VALUES (1)) AS "t" ("id"),
> (VALUES (1)) AS "t0" ("ID"){code}
> I think RelToSqlConverter should uniquify generated output names using the
> target dialect's case-sensitivity.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
