Hi all,
It's great to see Calcite already supports PTF syntax and support the
out-of-box new window syntax.
SELECT *
FROM TABLE(TUMBLE(TABLE Bid, DESCRIPTOR(bidtime), INTERVAL '10' MINUTES));
However, some people from the Flink community think that the TABLE()
keyword is a little verbose for use
Can we drop the word "polymorphic" from the discussion? Polymorphic
table functions are a valid ask, but can be a separate discussion.
This is about calling table functions without the TABLE keyword,
right?
Which is what I said to you four years ago:
https://issues.apache.org/jira/browse/CALCITE-1
In terms of SQL grammar to support omitting TABLE, there are actually two
changes for
SELECT *
FROM TABLE(TUMBLE(TABLE Bid, DESCRIPTOR(bidtime), INTERVAL '10' MINUTES));
You can support omitting the TABLE after the FROM, which makes the query
become:
SELECT *
FROM TUMBLE(TABLE Bid, DESCRIPTOR(bid
I think we can do them separately. And I think we should do the TABLE
first. The biggest problem is with namespaces - if you omit TABLE, you
have to deal with the possibility that there is a table (or view)
called FOO and also a parameterless table function called FOO. Not
sure how Oracle and SQL S
> Let's not use TUMBLE (or HOP, or SESSION) as the main example. It is
somewhat built-in (i.e. has special treatment in the code). Let's work
in terms of, say, the RAMP user-defined function. It is used in
several tests [1].
We may need to support all the user defined table functions with TABLE
ke
Hi all,
Yes, there are two separate discussions here.
1) omit TABLE() keyword for table function calls, i.e. CALCITE-1490
2) omit TABLE keyword for the table parameter in TVF.
Let's focus on the first discussion. If I understand correctly, the problem
is
the namespace conflict of table and table
>Are we planning to support it as a default syntax or as a dialect ? Say,
>maybe Oracle.
CALCITE-1490 suggests only add to SQL server, but as Oracle, Snowflake and
BigQuery seems all support the simplified syntax, it might be enough to
justify adding this support to default syntax?
>Another idea
> CALCITE-1490 suggests only add to SQL server, but as Oracle, Snowflake and
> BigQuery seems all support the simplified syntax, it might be enough to
> justify adding this support to default syntax?
Possibly, but I'd be cautious, because the semantics become ambiguous
if there are name clashes.
Thanks Julian ~
> Possibly, but I'd be cautious, because the semantics become ambiguous
if there are name clashes.
Assumes there is a table named TT and a table function named TT(param_a,
param_b), they are under the same namespace, do you mean
"FROM TT(param_a, param_b)" or "FROM TT(TABLE TT, p
Something like that. I guess if TT is a function with zero parameters
and also a table, then does TT in the following refer to the function
or the table?
SELECT *
FROM TT
Note that the TT function doesn't even have to be a table function.
Table functions are functions, and so are in the same
In current codebase, we actually never allows syntax like
SELECT *
FROM TT
because of 2 reasons:
1. The parser does not allow table function calls without parenthesis
2. SqlConformace.allowNiladicParentheses default returns false
In TableFunctionTest, I try to register the same name table and
I agree with Danny.
I think we can use the parentheses to distinguish table vs. table-function
and use different namespaces for validation?
Bets,
Jark
On Tue, 3 Nov 2020 at 15:25, Danny Chan wrote:
> In current codebase, we actually never allows syntax like
>
> SELECT *
> FROM TT
>
> because
12 matches
Mail list logo
