Chris Rice created CALCITE-5885:
-----------------------------------
Summary: 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
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)
