Hi,
sorry for jumping into the discussion so late. I had a quick look at the
FLIP. It looks very nice and detailed. I have one question that I could
not find in the FLIP itself. Maybe it is hidden in the long discussion
thread.
What are the return types of all functions? Do we introduce new types
with this FLIP? Also the RAW types should be avoided. Do all functions
return STRING/BOOLEAN?
Thanks,
Timo
On 31.12.19 09:39, Hequn Cheng wrote:
Thanks a lot for the update. +1 to start a vote.
On Tue, Dec 31, 2019 at 2:38 PM Forward Xu <forwardxu...@gmail.com> wrote:
Hi Jark, Hequn,
I have updated the documentation.
Best,
Forward
Forward Xu <forwardxu...@gmail.com> 于2019年12月29日周日 下午4:01写道：
Hi Jark, Hequn,
Thank you very much, Introducing new `TableSymbol`s sounds like a good
idea. +1 for the proposal.
I think this idea is good, I will add this in the documentation.
Best, Forward
Hequn Cheng <chenghe...@gmail.com> 于2019年12月29日周日 下午3:41写道：
Hi Jark,
Introducing new `TableSymbol`s sounds like a good idea. +1 for the
proposal.
@ForwardXu what do you think? Would be great if the document can be
updated
accordingly.
Best, Hequn
On Fri, Dec 27, 2019 at 4:14 PM Jark Wu <imj...@gmail.com> wrote:
Thanks for looking into the design Hequn. I agree it would be great to
have a full story design.
For the ON ERROR and ON EMPTY clause in Table API, some initial
thoughts in my mind is that
we can introduce some new `TableSymbol`s as the second parameter of
json
function, e.g. `JsonErrorStrategy`.
For example,
JSON_VALUE(v, 'lax $.b' ERROR ON ERROR)
== is equal to Table API ==>
v.jsonValue("lax $.b", JsonErrorStrategy.ERROR)
Best,
Jark
On Thu, 26 Dec 2019 at 23:37, Hequn Cheng <chenghe...@gmail.com>
wrote:
Hi Jark & ForwardXu,
The design doc looks very nice! Only some minor feedback from my
side.
As calcite has already implemented the JSON functions, I would
suppose
the semantics and implementation are right for SQL.
For TableAPI, I think the most important is to keep align with the
SQL(which has also been mentioned by Jark in the previous
discussion).
Have
an equivalent feature set for all APIs and maintain it otherwise
confusion
increases especially when more and more functions are added. The
document
has documented how to support TableAPI. I think this is very good!
And
it
would be better to also include ON ERROR or ON EMPTY for Table API.
We
can
implement these features step by step, but maybe we should design all
these
once for all to avoid API changes later. Meanwhile, these features
are
also
commonly required by users.
Would be great to also have your opinions!
Best,
Hequn
On Mon, Dec 23, 2019 at 10:15 AM Jark Wu <imj...@gmail.com> wrote:
Hi Forward,
Thanks for creating the FLIP. +1 to start a vote.
@Hequn Cheng <chenghe...@gmail.com> @Kurt Young <ykt...@gmail.com>
,
could you help to review the design doc too?
Best,
Jark
On Mon, 23 Dec 2019 at 10:10, tison <wander4...@gmail.com> wrote:
modified:
https://lists.apache.org/x/thread.html/b3c0265cc2b660fe11ce550b84a831a7606de12908ff7ff0959a4794@%3Cdev.flink.apache.org%3E
