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