[jira] [Commented] (CALCITE-5222) Support more EXTRACT field values (or allow arbitrary in parse?)
[
https://issues.apache.org/jira/browse/CALCITE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17572979#comment-17572979
]
Steven Talbot commented on CALCITE-5222:
Ah, totally, and I see that it was merged, thanks Julian!
> 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 )
> EXTRACT(TIME FROM ){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)
[jira] [Commented] (CALCITE-5222) Support more EXTRACT field values (or allow arbitrary in parse?)
[
https://issues.apache.org/jira/browse/CALCITE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 )
> EXTRACT(TIME FROM ){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)
[jira] [Commented] (CALCITE-5222) Support more EXTRACT field values (or allow arbitrary in parse?)
[
https://issues.apache.org/jira/browse/CALCITE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17572695#comment-17572695
]
Steven Talbot commented on CALCITE-5222:
^^ probably, sorry for missing that, though this would be a good reminder to
make it work in the parser as well, if that other issue doesn't cover the
parser.
> 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 )
> EXTRACT(TIME FROM ){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)
[jira] [Commented] (CALCITE-5222) Support more EXTRACT field values (or allow arbitrary in parse?)
[
https://issues.apache.org/jira/browse/CALCITE-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17572660#comment-17572660
]
Julian Hyde commented on CALCITE-5222:
--
Duplicate of CALCITE-5155, I think.
> 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 )
> EXTRACT(TIME FROM ){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)
