[
https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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, 60000: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)
