[
https://issues.apache.org/jira/browse/CALCITE-3955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099406#comment-17099406
]
Rui Wang edited comment on CALCITE-3955 at 5/4/20, 11:11 PM:
-------------------------------------------------------------
Thanks Julian. I digged into what you suggested and wanted to discuss a
specific thing about TableFunction interface [1]:
I believe one of the methods in this interface (either getRowType or
getElementType) is used to derive the "type" of returned table from the table
function.
For example: "select * from table_fun(table t);".
At a moment, validator will need to know what is the row type from table_fun to
expand star.
However, neither
{code:java}
RelDataType getRowType(RelDataTypeFactory typeFactory,
List<Object> arguments);
{code}
nor
{code:java}
// Some comments here
Type getElementType(List<Object> arguments);
{code}
has the power to derive that type because non's input contains the table's row
type.
So I think if I understand this interface right, one method should be somehow
changed to have an input that can derive the input table's row type.
For example, ideally, there could be " RelDataType
getRowType(RelDataTypeFactory typeFactory, List<RelDataType> argumentTypes);"
[1]:
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/schema/TableFunction.java#L31
was (Author: amaliujia):
Thanks Julian. I digged into what you suggested and wanted to discuss a
specific thing about TableFunction interface [1]:
I believe one of the methods in this interface (either getRowType or
getElementType) is used to derive the "type" of returned table from the table
function.
For example: "select * from table_fun(table t);".
At a moment, validator will need to know what is the row type from table_fun to
expand star.
However, neither
{code:java}
RelDataType getRowType(RelDataTypeFactory typeFactory,
List<Object> arguments);
{code}
nor
{code:java}
// Some comments here
Type getElementType(List<Object> arguments);
{code}
has the power to derive that type because non's input contains the table's row
type.
So I think if I understand this interface right, one method should be somehow
changed to have an input that can derive the input table's row type.
[1]:
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/schema/TableFunction.java#L31
> Remove the first operand of RexCall from SqlWindowTableFunction
> ---------------------------------------------------------------
>
> Key: CALCITE-3955
> URL: https://issues.apache.org/jira/browse/CALCITE-3955
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.22.0
> Reporter: Danny Chen
> Assignee: Danny Chen
> Priority: Major
> Fix For: 1.23.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In CALCITE-3382, we introduced TUMBLE window function to replace the
> deprecated group tumble window.
> But for query
> {code:sql}
> select *
> from table(tumble(table Shipments, descriptor(rowtime), INTERVAL '1' MINUTE))
> {code}
> the outputs plan is
> {code:xml}
> LogicalProject(ORDERID=[$0], ROWTIME=[$1], window_start=[$2], window_end=[$3])
> LogicalTableFunctionScan(invocation=[TUMBLE($1, DESCRIPTOR($1),
> 60000:INTERVAL MINUTE)], rowType=[RecordType(INTEGER ORDERID, TIMESTAMP(0)
> ROWTIME, TIMESTAMP(0) window_start, TIMESTAMP(0) window_end)])
> LogicalProject(ORDERID=[$0], ROWTIME=[$1])
> LogicalTableScan(table=[[CATALOG, SALES, SHIPMENTS]])
> {code}
> The first operand of TUMBLE rex call is always the last input field, but
> actually it represents the source table which is the input rel node.
> This issue remove the first operand from the RexCall because it is useless
> and confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
