[
https://issues.apache.org/jira/browse/CALCITE-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815801#comment-17815801
]
Julian Hyde commented on CALCITE-6254:
--------------------------------------
Thanks for this. The subject arose when we implemented {{CROSS APPLY}} in
CALCITE-1472; though {{CROSS APPLY}} is more elegant and concise without the
{{TABLE}} keyword, at the time I persuaded the author to treat them as separate
tasks. The relevant issue was CALCITE-1490; I'm going to mark that a duplicate
of this.
h3. Phoenix EXTEND extension
I don't think that the Phoenix extensions are used very much. If it helps, we
could make them optional, or mutually exclusive with your feature, or make the
{{EXTEND}} keyword mandatory. Your above example
{code:java}
SELECT * FROM EventLog(lastGCTime TIME) {code}
can also be written as
{code:java}
SELECT * FROM EventLog EXTEND (lastGCTime TIME){code}
and we could make that the only supported form.
h3. Validation
Does this introduce a namespace issue? Let's suppose that in the current
catalog there is a table called {{Foo}} and also a nilary (zero-argument)
function called {{Foo}}. If the user writes
{code:java}
SELECT * FROM Foo {code}
is it clear that they are referring to the table? Some dialects seem to allow
nilary functions to be called with no parentheses (e.g. {{CURRENT_TIMESTAMP)}}.
Do we need to declare that tables and functions occupy the same namespace (thus
making it illegal to have a table and function of the same name) or is it
always clear whether they are referencing a table or a function?
> Enable calling table functions without requiring TABLE() wrapper
> ----------------------------------------------------------------
>
> Key: CALCITE-6254
> URL: https://issues.apache.org/jira/browse/CALCITE-6254
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.36.0
> Reporter: Barry Kelly
> Priority: Minor
> Labels: parser
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Currently, when selecting from a table function, the function call needs to
> be wrapped in TABLE() like this:
> {{ SELECT * FROM TABLE(table_func('args'));}}
> Many dialects (SQL Server, PostgreSQL, BigQuery) do not require this:
> {{ SELECT * FROM table_func('args');}}
> The current Calcite grammar can be extended to permit this syntax without
> conflicting with other productions.
> There is a close call with the dynamic columns feature used by
> [Phoenix|https://phoenix.apache.org/dynamic_columns.html]
> {{ SELECT * FROM EventLog(lastGCTime TIME)}}
> It can be disambiguated with 3 tokens of lookahead, seeing past the '(' and
> identifier to the presence of a type production. The table extension clause
> for dynamic columns requires at least one field, so the empty case of '()' is
> not ambiguous either.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
