[
https://issues.apache.org/jira/browse/CALCITE-5885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie reassigned CALCITE-5885:
-----------------------------------
Assignee: Jiajun Xie
> SqlNode#toSqlString() does not honor dialect's supportsCharSet() flag on
> nested types
> -------------------------------------------------------------------------------------
>
> Key: CALCITE-5885
> URL: https://issues.apache.org/jira/browse/CALCITE-5885
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Chris Rice
> Assignee: Jiajun Xie
> Priority: Minor
> Attachments: CharsetTest.java
>
>
> Say we generate a RelNode corresponding to
> {code:java}
> SELECT CAST(c AS VARCHAR) FROM t
> {code}
> and we were to "unparse" that rel node back into the Postgres SQL dialect
> using
> {code:java}
> var converter = new RelToSqlConverter(PostgresqlSqlDialect.DEFAULT);
> SqlImplementor.Result result = converter.visitRoot(rel);
> SqlNode sqlNode = result.asStatement();
> var sql = sqlNode.toSqlString(PostgresqlSqlDialect.DEFAULT).getSql();
> {code}
> it would generate something like:
> {code:java}
> SELECT CAST("c" AS VARCHAR) AS "c"
> FROM "t"
> {code}
> Note that there is no charset information included in the cast, since the
> {{PostgresSqlDialect}} specifies that it does not support char sets:
> {code:java}
> @Override public boolean supportsCharSet() {
> return false;
> }
> {code}
> Given that, we would expect that unparsing
> {code:java}
> SELECT CAST(c AS VARCHAR ARRAY) FROM t
> {code}
> back into SQL would also generate a type with no charset specified, but it in
> fact generates
> {code:java}
> SELECT CAST("c" AS VARCHAR CHARACTER SET "ISO-8859-1" ARRAY) AS "c"
> FROM "t"
> {code}
> This seems to come from the way `SqlTypeUtil.convertTypeToSpec()` handles
> collection types.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
