[
https://issues.apache.org/jira/browse/CALCITE-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17106470#comment-17106470
]
Rui Wang edited comment on CALCITE-3970 at 5/13/20, 5:10 PM:
-------------------------------------------------------------
>Julian: So, how about allowing TABLE as an alternative to CURSOR, and
>deprecating CURSOR with an eye to eventually removing it?
I also didn't find the reference of CURSOR, and then what's the SQL semantics
of it becomes not clear to me. So deprecate it from the syntax makes sense to
me.
I tried to dig into CURSOR implementation and I find it makes sense. E.g.
Within a scope there is a list of CURSORS, and then in other places we can use
RexCorrelVariable to refer to CURSORS. CURSORS, for example, can be converted
to Rel's input. This fits table function implementation: table function has
table parameters, which becomes CURSORS and later becomes TableFunctionScan's
inputs. And in runtime, based on a RexCorrelVariable, table function impl will
know which input in TableFunctionScan to use.
So keep CURSOR idea in implementation seems useful.
> Danny: what kind of rex node should we translate the `col` column of table
> my_table
I think the suggestion here [1] is a working approach. See my description of
CURSOR implementation above.
However to adopt the implementation of [1], there will be some non-trivial
changes required.
A small attempt to summarize the idea by using CURSOR in table functions and
TableFunctionScan:
{code:java}
SqlNode:
FROM:
TableFunction: [TABLE[name]]:
During conversion:
FROM:
CURSORS:[SELECT * FROM name]
TableFunction: [CURSOR$0]:
After conversion to Rels:
TableFunctionScan:
inputs: [source1[type: a BIGINT], source2[type: b VARCHAR]]
table_function: [RexCorrelVariable(source1, type: a bigint)]
{code}
[1]:
https://issues.apache.org/jira/browse/CALCITE-3955?focusedCommentId=17097014&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17097014
was (Author: amaliujia):
>Julian: So, how about allowing TABLE as an alternative to CURSOR, and
>deprecating CURSOR with an eye to eventually removing it?
I also didn't find the reference of CURSOR, and then what's the SQL semantics
of it becomes not clear to me. So deprecate it from the syntax makes sense to
me.
I tried to dig into CURSOR implementation and I find it makes sense. E.g.
Within a scope there is a list of CURSORS, and then in other places we can use
RexCorrelVariable to refer to CURSORS. CURSORS, for example, can be converted
to Rel's input. This fits table function implementation: table function has
table parameters, which becomes CURSORS and later becomes TableFunctionScan's
inputs. And in runtime, based on a RexCorrelVariable, table function impl will
know which input in TableFunctionScan to use.
So keep CURSOR idea in implementation seems useful.
> Danny: what kind of rex node should we translate the `col` column of table
> my_table
I think the suggestion here [1] is a working approach. See my description of
CURSOR implementation above.
However to adopt the implementation of [1], there will be some non-trivial
changes required.
A small attempt to summarize the idea by using CURSOR in table functions and
TableFunctionScan:
{code:java}
SqlNode:
FROM:
TableFunction: [TABLE[name]]:
During conversion:
FROM:
CURSORS:[SELECT * FROM name]
TableFunction: [CURSOR$0]:
After conversion to Rels:
TableFunctionScan:
inputs: [source1[type: a BIGINT], source2[type: b VARCHAR]]
table_function: TUMBLE(RexCorrelVariable(source1, type: a bigint), ...)
{code}
[1]:
https://issues.apache.org/jira/browse/CALCITE-3955?focusedCommentId=17097014&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17097014
> Table-valued function TUMBLE uses non-standard syntax
> -----------------------------------------------------
>
> Key: CALCITE-3970
> URL: https://issues.apache.org/jira/browse/CALCITE-3970
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.22.0
> Reporter: Viliam Durina
> Priority: Major
>
> The currently supported syntax is this:
> {code:java}
> SELECT * FROM TABLE(TUMBLE(TABLE my_table, ...
> {code}
> But the SQL standard specifies that {{my_table}} must be in parentheses, such
> as here:
> {code:java}
> SELECT * FROM TABLE(TUMBLE(TABLE(my_table), ...
> {code}
> The second syntax is currently rejected with:
> {code:none}
> Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException:
> Encountered "(" at line 1, column 33.
> Was expecting one of:
> <BRACKET_QUOTED_IDENTIFIER> ...
> <QUOTED_IDENTIFIER> ...
> <BACK_QUOTED_IDENTIFIER> ...
> <IDENTIFIER> ...
> <UNICODE_QUOTED_IDENTIFIER> ...
> {code}
> I'm not sure if the currently supported syntax is optional, but I think it's
> not.
> I followed this document:
> [http://standards.iso.org/ittf/PubliclyAvailableStandards/c069776_ISO_IEC_TR_19075-7_2017.zip]
> The {{TABLE}} clause acts in both ways: (1) to convert a table value to a
> table object (when used in the {{FROM}} clause to convert the function
> result) and (2) to convert a table object to a table value (when used to
> convert arguments to a function).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
