You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Will Noble (Jira)" <ji...@apache.org> on 2023/02/15 19:16:00 UTC

[jira] [Assigned] (CALCITE-5526) Handle unparsing of literals based on type system

     [ https://issues.apache.org/jira/browse/CALCITE-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Will Noble reassigned CALCITE-5526:
-----------------------------------

    Assignee: Will Noble

> 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|https://issues.apache.org/jira/browse/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)