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