[
https://issues.apache.org/jira/browse/CALCITE-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17689422#comment-17689422
]
TJ Banghart commented on CALCITE-5526:
--------------------------------------
So here's an idea given Julian's comments:
We add to the validator a map of type aliases used during validation (but give
precedence to UDTs). The type aliases would be configurable as a connection
property similar to [lexical
policies|https://github.com/apache/calcite/blob/79879f92abc4f2279496a0e6ca9066d9d24a1457/core/src/main/java/org/apache/calcite/config/Lex.java#L27].
Calcite would have several prebuilt type alias maps such as
{{TypeAliases.BIG_QUERY}} or {{{}TypeAliases.SNOWFLAKE, etc{}}}. These type
maps become bound to a dialect by its [context
|https://github.com/apache/calcite/blob/79879f92abc4f2279496a0e6ca9066d9d24a1457/core/src/main/java/org/apache/calcite/sql/SqlDialect.java#L1392-L1431]class
(again, similar to {{{}Lex{}}}).
These maps could then help inform a dialect's
{{{}[RelDataTypeSystem|https://github.com/apache/calcite/blob/79879f92abc4f2279496a0e6ca9066d9d24a1457/core/src/main/java/org/apache/calcite/rel/type/RelDataTypeSystem.java#L34]{}}}.
This would at least allow us to have a shared alias map between validation and
unparsing.
Alternatively, if we want to stick with aliasing via UDTs, we may be able to
just override
{{[RelDataTypeSystem#getLiteral|https://github.com/apache/calcite/blob/79879f92abc4f2279496a0e6ca9066d9d24a1457/core/src/main/java/org/apache/calcite/rel/type/RelDataTypeSystem.java#L63-L64]}}
to return the expected type string for each dialect.
> 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)
