[
https://issues.apache.org/jira/browse/CALCITE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572696#comment-17572696
]
Julian Hyde commented on CALCITE-5222:
--------------------------------------
I believe that CALCITE-5143, which is linked to CALCITE-5155, handles most or
all of the parser aspects.
> Support more EXTRACT field values (or allow arbitrary in parse?)
> ----------------------------------------------------------------
>
> Key: CALCITE-5222
> URL: https://issues.apache.org/jira/browse/CALCITE-5222
> Project: Calcite
> Issue Type: Improvement
> Reporter: Steven Talbot
> Priority: Major
>
> E.g. a number of BigQuery EXTRACTs from
> [https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions#extract]
> do not parse with the babel parser
> {noformat}
> EXTRACT(DAYOFWEEK FROM <date_col>)
> EXTRACT(TIME FROM <date_col>){noformat}
> (also DATE, DATETIME, DAYOFYEAR... there may be others)
> Other dialects may have similar problems, e.g. "EXTRACT(JULIAN...)" in
> Postgres looks like it wouldn't parse either.
> Calcite chasing down every value ever implemented by a DB vendor here seems
> like it might be too tall of a task, but perhaps allowing for an arbitrary
> keyword in that syntactic position, and then users of the parser would have
> to handle it if the parse of the EXTRACT comes out with an arbitrary symbol,
> rather than a TimeUnit enum value for one of the known EXTRACT fields.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
