[
https://issues.apache.org/jira/browse/CALCITE-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17632492#comment-17632492
]
Mark Grey edited comment on CALCITE-4362 at 11/11/22 5:59 PM:
--------------------------------------------------------------
Thank you for the feedback [~julianhyde]!
* I'll reconsider the naming in the next draft. As a sanity check, how does
singular {{SystemColumn}} sound? Perhaps there's a better name referring more
directly to the presence of a given system column in a certain context. I'll
look through the code for inspiration.
* Will definitely give this a try using the example you provided! It looks
like a more logical container to attach this to.
* Yes, I think we should almost certainly expand this proposal to include that.
I think there are advantages to designing this in at the outset to incoporate
some knowledge of the table's type. We could probably start with the example
provided by the original ticket formulation, and associate {{_PARTITIONDATE}}
and {{_PARTITIONTIME}} drawn from the BigQuery convention only in the case of
an underlying {{TemporalTable}}. I can probably build off the example I took
from {{SqlLibrary}} to improve this by taking a table implementation into
account as well. Should we redefine the ticket to capture this?
* This last point is interesting, and not something I had considered. My
(probably naive) assumption is that in the case of query-time columns, there
are classes of operators that do similar (inject columns not formally mentioned
in the select projection) and so it's possible the implementation for that
would need to be more broadly focused on those? {{RANK}} and {{ROWNUMBER}}
come to mind from the BigQuery setting I'm most familiar with. Perhaps these
are distinct from system columns if so?
was (Author: mgthesecond):
Thank you for the feedback [~julianhyde]!
* I'll reconsider the naming in the next draft. As a sanity check, how does
singular {{SystemColumn}} sound? Perhaps there's a better name referring more
directly to the presence of a given system column in a certain context. I'll
look through the code for inspiration.
* Will definitely give this a try using the example you provided! It looks
like a more logical container to attach this to.
* Yes, I think we should almost certainly expand this proposal to include that.
I think there are advantages to designing this in at the outset to incoporate
some knowledge of the table's type. We could probably start with the example
provided by the original ticket formulation, and associate {{_PARTITIONDATE}}
and {{_PARTITIONTIME}} drawn from the BigQuery convention only in the case of
an underlying {{TemporalTable}}. I can probably build off the example I took
from {{SqlLibrary}} to improve this by taking a table implementation into
account as well. Should we redefine the ticket to capture this?
* This last point is interesting, and not something I had considered. My
(probably naave) assumption is that in the case of query-time columns, there
are classes of operators that do similar (inject columns not formally mentioned
in the select projection) and so it's possible the implementation for that
would need to be more broad? {{RANK}} and {{ROWNUMBER}} come to mind from the
BigQuery setting I'm most familiar with. Perhaps these are distinct from
system columns if so?
> Unable to parse queries that use BigQuery pseudo columns
> _PARTITIONDATE/_PARTITIONTIME
> --------------------------------------------------------------------------------------
>
> Key: CALCITE-4362
> URL: https://issues.apache.org/jira/browse/CALCITE-4362
> Project: Calcite
> Issue Type: Bug
> Components: babel
> Reporter: Justin Swett
> Assignee: Julian Hyde
> Priority: Major
>
> BigQuery supports partitioned tables using pseudo columns "_PARTITIONDATE"
> e.g. The following table has two columns you can select from but also
> partitions the data by creation date
> {code:java}
> CREATE or REPLACE TABLE #{table} (
> transaction_id STRING,
> order_date DATE )
> PARTITION BY _PARTITIONDATE
> {code}
>
> The following queries cannot be validated
> {code:java}
> select * from #{table} where _PARTITIONDATE = '2020-11-03' ;
> -- OR
> select * from #{table} where _PARTITIONTIME = '2020-11-03' ;{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
