[
https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16928836#comment-16928836
]
Rui Wang edited comment on CALCITE-3340 at 9/12/19 7:30 PM:
------------------------------------------------------------
This is a pretty important moment so I will confirm more details:
1. Calcite will need maintain both GROUP BY TUMBLE and FROM TABLE(TUMBLE).
2. Sqlkind has already had TUMBLE, HOP, SESSION and their start and end.
3. Because Parser.jj does not have dedicated match for TUMBLE/HOP/SESSION,
these functions will be UnresolvedFunction after parsing. In validator, there
will be a unresolved function lookup from operator table to find operators by
operator name. See
[SqlValidatorImpl.java#L1750|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L1750]
Thus I believe the recommendation for table-value function TUMBLE is:
1. a new operator defined in SqlStdOperatorTable.
2. The new operator will have a static instance with another variable name,
e.g. TUMBLE_TABLE_FUNCTION. It's because
[TUMBLE|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlStdOperatorTable.java#L2255]
is already defined.
3. For the new operator, reuse "TUMBLE" as operator name and SqlKind.TUMBLE for
node kind.
Any comment on my summary?
was (Author: amaliujia):
This is a pretty important moment so I will confirm more details:
1. Calcite will need maintain both GROUP BY TUMBLE and FROM TABLE(TUMBLE).
2. Sqlkind has already had TUMBLE, HOP, SESSION and their start and end.
3. Because Parser.jj does not have dedicated match for TUMBLE/HOP/SESSION,
these functions will be UnresolvedFunction after parsing. In validator, there
will be a unresolved function lookup from operator table to find operators by
operator name, and operator names should be unique. See
[SqlValidatorImpl.java#L1750|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L1750]
Thus I believe the recommendation for table-value function TUMBLE is:
1. a new operator defined in SqlStdOperatorTable.
2. The new operator will have a static instance with another variable name,
e.g. TUMBLE_TABLE_FUNCTION. It's because
[TUMBLE|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlStdOperatorTable.java#L2255]
is already defined.
3. The real query syntax for table-value function TUMBLE will also have to be
changed to: "SELECT * FROM TABLE(TUMBLE_TABLE_FUNCTION(...))". This is because
of the operator name lookup mentioned above so we have to differentiate TUMBLE
and TUMBLE_TABLE_FUNCTION.
Any comment on my summary?
> Make TUMBLE be accepted as an operand for COLLECTION_TABLE(TABLE syntax) in
> validator
> -------------------------------------------------------------------------------------
>
> Key: CALCITE-3340
> URL: https://issues.apache.org/jira/browse/CALCITE-3340
> Project: Calcite
> Issue Type: Sub-task
> Reporter: Rui Wang
> Assignee: Rui Wang
> Priority: Major
>
> For query:
> SELECT *
> FROM TABLE(TUMBLE(
> TABLE ORDERS,
> DESCRIPTOR(ROWTIME),
> INTERVAL '10' MINUTE))
> (note reuse TUMBLE operator than use a new unresolved one)
> Calcite validator will does a step to do registration and
> "TABLE(TUMBLE(...))" will hit [1], where "TUMBLE(...)" will be passed to [2]
> again but there is no matching Sqlkind handling for "TUMBLE" (note that
> TUMBLE's node kind is TUMBLE).
> It seems we should support TUMBLE in [2]. The details of how to support it
> needs a bit more discussion and prototyping.
> [1]:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2244
> [2]:https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L2031
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
