[
https://issues.apache.org/jira/browse/CALCITE-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Lee updated CALCITE-5424:
--------------------------------
Description:
Currently if you write {{TIMESTAMP '1969-07-20 22:56:00'}} it will be
converted to a value of type {{{}TIMESTAMP{}}}. But if someone has set a custom
type mapping where the name {{TIMESTAMP}} corresponds to the {{TIMESTAMP WITH
LOCAL TIME ZONE}} type then the literal value should be of that type.
Custom type mappings are specified by defining user-defined types in the
schema; see the method
[Schema.getType|https://calcite.apache.org/javadocAggregate/org/apache/calcite/schema/Schema.html#getType(java.lang.String)].
The contents of the string are currently handled by the parser. But in order to
implement this change, the parsing of that string will need to be deferred to
validation time (when the actual type is known, not just its name). This
applies to literals {{TIMESTAMP}}, {{DATE}}, {{TIME}}, {{ARRAY}}, {{INTERVAL}}.
The parser currently emits subclasses of {{SqlLiteral}}, namely
{{SqlTimestampLiteral}}, {{SqlDateLiteral}}, {{SqlTimeLiteral}},
{{SqlArrayLiteral}}, {{SqlIntervalLiteral}}. But after this change, the parser
will emit a new subclass, {{SqlUnknownLiteral}} (with identifying {{tag}})
instead of all of these.
Also as part of this change, add BigQuery-compatible literals:
* {{NUMERIC '0'}}
* {{BIGNUMERIC '0'}}
* {{DATETIME '2014-09-27 12:30:00.45'}}
* {{JSON 'json_formatted_data'}}
And a {{TIMESTAMP WITH LOCAL TIME ZONE}} literal:
* {{TIMESTAMP WITH LOCAL TIME ZONE '1969-07-21 02:56:00'}}
was:
Currently if you write {{TIMESTAMP '1969-07-20 22:56:00'}} it will be
converted to a value of type {{{}TIMESTAMP{}}}. But if someone has set a custom
type mapping where the name {{TIMESTAMP}} corresponds to the {{TIMESTAMP WITH
LOCAL TIME ZONE}} type then the literal value should be of that type.
Custom type mappings are specified by defining user-defined types in the
schema; see the method
[Schema.getType|https://calcite.apache.org/javadocAggregate/org/apache/calcite/schema/Schema.html#getType(java.lang.String)].
The contents of the string are currently handled by the parser. But in order to
implement this change, the parsing of that string will need to be deferred to
validation time (when the actual type is known, not just its name). This
applies to literals {{TIMESTAMP}}, {{DATE}}, {{TIME}}, {{ARRAY}}, {{INTERVAL}}.
The parser currently emits subclasses of {{SqlLiteral}}, namely
{{SqlTimestampLiteral}}, {{SqlDateLiteral}}, {{SqlTimeLiteral}},
{{SqlArrayLiteral}}, {{SqlIntervalLiteral}}. But after this change, the parser
will emit a new subclass, {{SqlTaggedLiteral}} instead of all of these.
Also as part of this change, add BigQuery-compatible literals:
* {{NUMERIC '0'}}
* {{BIGNUMERIC '0'}}
* {{DATETIME '2014-09-27 12:30:00.45'}}
* {{JSON 'json_formatted_data'}}
And a {{TIMESTAMP WITH LOCAL TIME ZONE}} literal:
* {{TIMESTAMP WITH LOCAL TIME ZONE '1969-07-21 02:56:00'}}
> Customize handling of literals based on type system
> ---------------------------------------------------
>
> Key: CALCITE-5424
> URL: https://issues.apache.org/jira/browse/CALCITE-5424
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
> Priority: Major
>
> Currently if you write {{TIMESTAMP '1969-07-20 22:56:00'}} it will be
> converted to a value of type {{{}TIMESTAMP{}}}. But if someone has set a
> custom type mapping where the name {{TIMESTAMP}} corresponds to the
> {{TIMESTAMP WITH LOCAL TIME ZONE}} type then the literal value should be of
> that type.
> Custom type mappings are specified by defining user-defined types in the
> schema; see the method
> [Schema.getType|https://calcite.apache.org/javadocAggregate/org/apache/calcite/schema/Schema.html#getType(java.lang.String)].
> The contents of the string are currently handled by the parser. But in order
> to implement this change, the parsing of that string will need to be deferred
> to validation time (when the actual type is known, not just its name). This
> applies to literals {{TIMESTAMP}}, {{DATE}}, {{TIME}}, {{ARRAY}},
> {{INTERVAL}}. The parser currently emits subclasses of {{SqlLiteral}}, namely
> {{SqlTimestampLiteral}}, {{SqlDateLiteral}}, {{SqlTimeLiteral}},
> {{SqlArrayLiteral}}, {{SqlIntervalLiteral}}. But after this change, the
> parser will emit a new subclass, {{SqlUnknownLiteral}} (with identifying
> {{tag}}) instead of all of these.
> Also as part of this change, add BigQuery-compatible literals:
> * {{NUMERIC '0'}}
> * {{BIGNUMERIC '0'}}
> * {{DATETIME '2014-09-27 12:30:00.45'}}
> * {{JSON 'json_formatted_data'}}
>
> And a {{TIMESTAMP WITH LOCAL TIME ZONE}} literal:
> * {{TIMESTAMP WITH LOCAL TIME ZONE '1969-07-21 02:56:00'}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
