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
Hi all,
+1 for text over images whenever possible (for the same reason, it's
convenient to have it indexed by search engines).
+0 for image support, I see the benefits but I am afraid we will see less
and less text/stack traces.
Best regards,
Alessandro
On Wed, 28 Oct 2020 at 01:13, Michael Mior
Danny Chen created CALCITE-4364:
---
Summary: "a in (1, 2) and a = 1" should be simplified to "a=1"
Key: CALCITE-4364
URL: https://issues.apache.org/jira/browse/CALCITE-4364
Project: Calcite
Issue
To all who vote for "disallow images",
Do you think it really helps if the images are forbidden?
People who write to dev@ list and attach the stacktrace as an image don't
really know if the list accepts images or not.
Making images forbidden does not help to teach people to
attach stacktraces as t
Caizhi Weng created CALCITE-4365:
Summary: SEARCHes in ANDs and ORs cannot be simplified if the
complexity of its SARG can actually be reduced to 1
Key: CALCITE-4365
URL: https://issues.apache.org/jira/browse/CALC
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
Julian Hyde created CALCITE-4366:
Summary: LatticeSuggester should treat UNION / VALUES
sub-expressions as tables
Key: CALCITE-4366
URL: https://issues.apache.org/jira/browse/CALCITE-4366
Project: Cal
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
>People who write to dev@ list and attach the stacktrace as an image don't
>really know if the list accepts images or not.
>Making images forbidden does not help to teach people to
>attach stacktraces as text.
I guess the way will be when we see those cases, we reply to ask to replace
the image by
> 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
Yes, +1 to handle it case by case with proper reminders.
Rui Wang 于2020年10月30日周五 上午6:19写道：
> >People who write to dev@ list and attach the stacktrace as an image don't
> >really know if the list accepts images or not.
> >Making images forbidden does not help to teach people to
> >attach stacktra
John Bodley created CALCITE-4367:
Summary: Incorrect documentation for Avatica JSON request/response
signatures
Key: CALCITE-4367
URL: https://issues.apache.org/jira/browse/CALCITE-4367
Project: Calci
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
14 matches
Mail list logo
