[
https://issues.apache.org/jira/browse/CALCITE-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16945144#comment-16945144
]
Rui Wang commented on CALCITE-3340:
-----------------------------------
Move more relevant discussions from https://github.com/apache/calcite/pull/1457.
>From Julian
{code:java}
I take your point that with the limited namespace we can't have two different
functions called TUMBLE.
Therefore changing the Parser.jj seems to make sense.
However, we see the future as being TUMBLE (or any user-defined table function)
in the FROM clause. Therefore how about adding parser support for TUMBLE (and
HOP) in the GROUP BY clause? This would be deprecated functionality, and
removed at some point. The parser would be hard-wired to create calls to that
function, and therefore function does not need to be called literally TUMBLE.
It could be called "TUMBLE_OLD" or whatever.
{code}
>From Rui
{code:java}
@julianhyde I like your idea. So we save "TUMBLE" for one operator and use a
new name for another operator, but Parser will code one so it will create an
operator directly without caring about operator name. By doing so operator
overloading is also avoided. I like it.
You suggest code old TUMBLE into parser(thus rename old TUMBLE operator to
maybe "TUMBLE_old"), which seems to me there will be a backward compatible
issue: maybe someone is already depending on "TUMBLE" as the name to lookup the
old TUMBLE operator? If this is a concern it would be better to use new name
for the new operator and code the new operator into Parser. And then we should
start a deprecation process at some point to say only maintain old operator for
2 ~ 3 versions, and finally switch the name back. What do you think?
{code}
>From Julian
{code:java}
Don't worry about backwards compatibility in SqlStdOperatorTable. I doubt
anyone is using the fields directly (other than via our parser). We'll get a
better result if we don't slavishly preserve the past.
{code}
> Table Function TUMBLE as a SQL operator in SqlStdOperatorTable
> --------------------------------------------------------------
>
> 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: 2h 10m
> 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)
