[
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:42 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}}.
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, 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)
