[jira] [Comment Edited] (CALCITE-3340) Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator
[
https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937044#comment-16937044
]
Rui Wang edited comment on CALCITE-3340 at 9/24/19 5:49 PM:
I can see many of the functions are coded into parser (e.g. SUBSTRING, TRIM,
etc.), and they are not looked up by name.
However, based on my test and my read from code, both old TUMBLE(the group
function) and new TUMBLE(table function) don't follow that, thus these two
operators are looked up by name(and that's why same "TUMBLE" as operator name
leads to operator overloading and I always observed ). Either same SqlKind
(e.g. SqlKind.TUMBLE) or different SqlKind(e.g. assign OTHER_FUNCTION to new
TUMBLE operator) does not change the lookup name. Also, "TUMBLE" is not a
keyword in parser.jj
So do you suggest I code both TUMBLE into parser, like other built-in
operators? I can give a try on this idea.
was (Author: amaliujia):
I can see many of the functions are coded into parser (e.g. SUBSTRING, TRIM,
etc.), and they are not looked up by name.
However, based on my test and my read from code, both old TUMBLE(the group
function) and new TUMBLE(table function) don't follow that, thus these two
operators are looked up by name(and that's why same "TUMBLE" as operator name
leads to operator overloading and I always observed ). Either same SqlKind
(e.g. SqlKind.TUMBLE) or different SqlKind(e.g. assign OTHER_FUNCTION to new
TUMBLE operator) does not change the lookup name.
So do you suggest I code both TUMBLE into parser, like other built-in
operators? I can give a try on this idea.
> Make TUMBLE be accepted as an operand for "FROM TABLE()" 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
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The goal of this JIRA is to generate a logical plan for the following query:
> {code:java}
> SELECT *
> FROM TABLE(TUMBLE(
> TABLE ORDERS,
> INTERVAL '10' MINUTE))
> {code}
> This SQL query does not have DESCRIPTOR included, which is being tracked and
> discussed by CALCITE-3339.
> I expect we should generate a logical plan from this query that is similar to
> the following:
> {code:java}
> LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3], wstart=[$4],
> wend=[$5])
> LogicalTableFunctionScan(invocation=[TUMBLE($3, 6:INTERVAL MINUTE)],
> rowType=[RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID, VARCHAR(10) PRODUCT,
> INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)])
> LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3])
> LogicalTableScan(table=[[ORINOCO, ORDERS]])
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3340) Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator
[
https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937044#comment-16937044
]
Rui Wang edited comment on CALCITE-3340 at 9/24/19 5:45 PM:
I can see many of the functions are coded into parser (e.g. SUBSTRING, TRIM,
etc.), and they are not looked up by name.
However, based on my test and my read from code, both old TUMBLE(the group
function) and new TUMBLE(table function) don't follow that, thus these two
operators are looked up by name(and that's why same "TUMBLE" as operator name
leads to operator overloading and I always observed ). Either same SqlKind
(e.g. SqlKind.TUMBLE) or different SqlKind(e.g. assign OTHER_FUNCTION to new
TUMBLE operator) does not change the lookup name.
So do you suggest I code both TUMBLE into parser, like other built-in
operators? I can give a try on this idea.
was (Author: amaliujia):
I can see many of the functions are coded into parser (e.g. SUBSTRING, TRIM,
etc.), and they are not looked up by name.
However, based on my test and my read from code, both old TUMBLE(the group
function) and new TUMBLE(table function) don't follow that, thus these two
operators are looked up by name(and that's why same "TUMBLE" as operator name
leads to operator overloading and I always observed ). Either same SqlKind
(e.g. SqlKind.TUMBLE) or different SqlKind(e.g. assign OTHER_FUNCTION to new
TUMBLE operator) does not change the lookup name.
So do you suggest I code both TUMBLE into parser, like other built-in operators?
> Make TUMBLE be accepted as an operand for "FROM TABLE()" 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
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The goal of this JIRA is to generate a logical plan for the following query:
> {code:java}
> SELECT *
> FROM TABLE(TUMBLE(
> TABLE ORDERS,
> INTERVAL '10' MINUTE))
> {code}
> This SQL query does not have DESCRIPTOR included, which is being tracked and
> discussed by CALCITE-3339.
> I expect we should generate a logical plan from this query that is similar to
> the following:
> {code:java}
> LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3], wstart=[$4],
> wend=[$5])
> LogicalTableFunctionScan(invocation=[TUMBLE($3, 6:INTERVAL MINUTE)],
> rowType=[RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID, VARCHAR(10) PRODUCT,
> INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)])
> LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3])
> LogicalTableScan(table=[[ORINOCO, ORDERS]])
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3340) Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator
[
https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16930845#comment-16930845
]
Rui Wang edited comment on CALCITE-3340 at 9/16/19 8:30 PM:
I see. Thanks for bringing it up.
To clarify, I am aiming to generate a logical plan for the following query by
PlannerImpl:
SELECT *
FROM TABLE(TUMBLE(
TABLE ORDERS,
INTERVAL '10' MINUTE))
This SQL query does not have DESCRIPTOR included, which is being tracked and
discussed by CALCITE-3339.
I expect we should generate a logical plan from this query that is similar to
the following:
{code:java}
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3], wstart=[$4],
wend=[$5])
LogicalTableFunctionScan(invocation=[TUMBLE($3, 6:INTERVAL MINUTE)],
rowType=[RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID, VARCHAR(10) PRODUCT,
INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)])
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3])
LogicalTableScan(table=[[ORINOCO, ORDERS]])
{code}
I just updated JIRA title a bit and hopeful now it is more understandable.
was (Author: amaliujia):
I see. Thanks for bringing it up.
To clarify, I am aiming to generate a logical plan for the following query by
PlannerImpl:
SELECT *
FROM TABLE(TUMBLE(
TABLE ORDERS,
INTERVAL '10' MINUTE))
This SQL query does not have DESCRIPTOR included, which is being tracked and
discussed by CALCITE-3339.
I expect we should generate a logical plan from this query that is similar to
the following:
{code:java}
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3], wstart=[$4],
wend=[$5])
LogicalTableFunctionScan(invocation=[TUMBLE($3, 6:INTERVAL MINUTE)],
rowType=[RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID, VARCHAR(10) PRODUCT,
INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)])
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3])
LogicalTableScan(table=[[ORINOCO, ORDERS]])
{code}
> Make TUMBLE be accepted as an operand for "FROM TABLE()" 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
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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)
[jira] [Comment Edited] (CALCITE-3340) Make TUMBLE be accepted as an operand for "FROM TABLE()" in validator
[
https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16930845#comment-16930845
]
Rui Wang edited comment on CALCITE-3340 at 9/16/19 8:30 PM:
I see. Thanks for bringing it up.
To clarify, I am aiming to generate a logical plan for the following query by
PlannerImpl:
{code:java}
SELECT *
FROM TABLE(TUMBLE(
TABLE ORDERS,
INTERVAL '10' MINUTE))
{code}
This SQL query does not have DESCRIPTOR included, which is being tracked and
discussed by CALCITE-3339.
I expect we should generate a logical plan from this query that is similar to
the following:
{code:java}
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3], wstart=[$4],
wend=[$5])
LogicalTableFunctionScan(invocation=[TUMBLE($3, 6:INTERVAL MINUTE)],
rowType=[RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID, VARCHAR(10) PRODUCT,
INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)])
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3])
LogicalTableScan(table=[[ORINOCO, ORDERS]])
{code}
I just updated JIRA title a bit and hopeful now it is more understandable.
was (Author: amaliujia):
I see. Thanks for bringing it up.
To clarify, I am aiming to generate a logical plan for the following query by
PlannerImpl:
SELECT *
FROM TABLE(TUMBLE(
TABLE ORDERS,
INTERVAL '10' MINUTE))
This SQL query does not have DESCRIPTOR included, which is being tracked and
discussed by CALCITE-3339.
I expect we should generate a logical plan from this query that is similar to
the following:
{code:java}
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3], wstart=[$4],
wend=[$5])
LogicalTableFunctionScan(invocation=[TUMBLE($3, 6:INTERVAL MINUTE)],
rowType=[RecordType(TIMESTAMP(0) ROWTIME, INTEGER ID, VARCHAR(10) PRODUCT,
INTEGER UNITS, TIMESTAMP(0) wstart, TIMESTAMP(0) wend)])
LogicalProject(ROWTIME=[$0], ID=[$1], PRODUCT=[$2], UNITS=[$3])
LogicalTableScan(table=[[ORINOCO, ORDERS]])
{code}
I just updated JIRA title a bit and hopeful now it is more understandable.
> Make TUMBLE be accepted as an operand for "FROM TABLE()" 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
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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)
