[ https://issues.apache.org/jira/browse/CALCITE-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17689357#comment-17689357 ]
TJ Banghart commented on CALCITE-5526: -------------------------------------- [~wnoble] Elsewhere you expressed concern on relying on {{CalciteCatalogReader}} within {{{}SqlDialect{}}}. Could you restate those concerns here? That seemed like a reasonable approach since any user defined types will be mapped to a schema. Alternatively, shouldn't specific {{SqlDialect}} classes just handle this by overriding {{unparseDateTimeLiteral}} and related methods? (ex. [Clickhouse|https://github.com/apache/calcite/blob/79879f92abc4f2279496a0e6ca9066d9d24a1457/core/src/main/java/org/apache/calcite/sql/dialect/ClickHouseSqlDialect.java#L121-L136]) > 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)