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
>>>
>>
