[
https://issues.apache.org/jira/browse/CALCITE-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776449#comment-17776449
]
Will Noble edited comment on CALCITE-5526 at 10/18/23 1:50 AM:
---------------------------------------------------------------
There are actually 2 different scenarios:
1. The program parses a query using a UDT map, and ends up with
{{SqlUnknownLiteral}} and {{SqlUserDefinedTypeNameSpec}} nodes in the AST. The
program never bothers converting that AST into a relational expression, and
simply unparses it in a specific dialect. I'm not sure how relevant this
scenario is to anybody, or if it even makes a ton a sense. It's not
particularly relevant to us. It would also be the annoying scenario to support;
we would have to consult the type mapping for these {{SqlUnknownLiteral}} and
{{SqlUserDefinedTypeNameSpec}} nodes during unparsing.
2. The program parses the query, converts to {{RelNode}} form, does whatever,
then converts back to {{SqlNode}} form, and *then* unparses in a specific
dialect. This is the scenario we really care about. In this scenario, all those
"unknown" and "user-defined" nodes have disappeared; replaced by their
canonical types. This would be easy to support: we just hardcode the mapping in
{{SqlDialect.unparseDateTimeLiteral}} and {{SqlDialect.getCastSpec}} for each
particular dialect.
I'm inclined to move forward on scenario #2. Seems like they're actually fairly
independent issues. The former only deals with those unknown/user-defined SQL
nodes, and the latter only deals with "canonical" nodes like
{{SqlBasicTypeNameSpec}}.
The reason I question whether scenario #1 even makes sense is that it implies
programs will always want to unparse a query in the same context (schema and
possibly dialect) that it was parsed. This may not be true, and if it's not, it
becomes complicated for the program to get it right every time. In scenario #2,
all that context has already been lost anyway.
was (Author: wnoble):
There are actually 2 different scenarios:
1. The program parses a query using a UDT map, and ends up with
{{SqlUnknownLiteral}} and {{SqlUserDefinedTypeNameSpec}} nodes in the AST. The
program never bothers converting that AST into a relational expression, and
simply unparses it in a specific dialect. I'm not sure how relevant this
scenario is to anybody, or if it even makes a ton a sense. It's not
particularly relevant to us. It would also be the annoying scenario to support;
we would have to consult the type mapping for these {{SqlUnknownLiteral}} and
{{SqlUserDefinedTypeNameSpec}} nodes during unparsing.
2. The program parses the query, converts to {{RelNode}} form, does whatever,
then converts back to {{SqlNode}} form, and *then* unparses in a specific
dialect. This is the scenario we really care about. In this scenario, all those
"unknown" and "user-defined" nodes have disappeared; replaced by their
canonical types. This would be easy to support: we just hardcode the mapping in
{{SqlDialect.unparseDateTimeLiteral}} and {{SqlDialect.getCastSpec}} for each
particular dialect.
I'm inclined to move forward on scenario #2. Seems like they're actually fairly
independent issues. The former only deals with those unknown/user-defined SQL
nodes, and the latter only deals with "canonical" nodes like
{{SqlBasicTypeNameSpec}}.
> Handle unparsing of literals based on type system
> -------------------------------------------------
>
> Key: CALCITE-5526
> URL: https://issues.apache.org/jira/browse/CALCITE-5526
> Project: Calcite
> Issue Type: Task
> Reporter: Will Noble
> Assignee: Will Noble
> Priority: Minor
>
> CALCITE-5424 dealt with parsing date/time literals via a custom type system,
> however there is still no way to unparse them via the same type system. This
> is handled in
> [SqlDialect.unparseDateTimeLiteral|https://github.com/apache/calcite/blob/a0e119ea42def418957f214f539469f1aba76c18/core/src/main/java/org/apache/calcite/sql/SqlDialect.java#L468]
> which simply calls the literal object's {{toString()}} method.
> The literal object (a subclass of {{SqlAbstractDateTimeLiteral}}) should not
> be able to determine it's own unparsed representation by itself since it
> could be unparsed in any dialect. Since the current system for resolving
> custom types relies on access to the catalog, it appears we'll need to
> introduce to {{SqlDialect}} a dependency on {{CalciteCatalogReader}} so it
> can use the same mappings for unparsing as it does for parsing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
