[jira] [Commented] (CALCITE-5885) SqlNode#toSqlString() does not honor dialect's supportsCharSet() flag on nested types
[
https://issues.apache.org/jira/browse/CALCITE-5885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753012#comment-17753012
]
Jiajun Xie commented on CALCITE-5885:
-
Fixed in
[6974126|https://github.com/apache/calcite/commit/697412624ef6baf0bf94554a51a5f7ed54d09ce7],
thank [~chrisrice] for your review.
> 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
> Labels: pull-request-available
> 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)
[jira] [Commented] (CALCITE-5885) SqlNode#toSqlString() does not honor dialect's supportsCharSet() flag on nested types
[
https://issues.apache.org/jira/browse/CALCITE-5885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17751368#comment-17751368
]
Jiajun Xie commented on CALCITE-5885:
-
Hi, [~chrisrice]
I fixed it, welcome to review it:
https://github.com/apache/calcite/pull/3349/files
> 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
> Labels: pull-request-available
> 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)
[jira] [Commented] (CALCITE-5885) SqlNode#toSqlString() does not honor dialect's supportsCharSet() flag on nested types
[
https://issues.apache.org/jira/browse/CALCITE-5885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750034#comment-17750034
]
Chris Rice commented on CALCITE-5885:
-
Attached a {{CharsetTest.java}} file containing the smallest self-contained
example I could conjure.
> 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
>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)
