+1 (binding)

On Thu, Sep 8, 2022 at 9:12 PM Jacques Nadeau <jacq...@apache.org> wrote:
>
> My vote continues to be +1
>
> On Thu, Sep 8, 2022 at 11:44 AM Neal Richardson <neal.p.richard...@gmail.com>
> wrote:
>
> > +1
> >
> > Neal
> >
> > On Thu, Sep 8, 2022 at 2:15 PM Ashish <paliwalash...@gmail.com> wrote:
> >
> > > +1 (non-binding)
> > >
> > > On Thu, Sep 8, 2022 at 9:41 AM Gavin Ray <ray.gavi...@gmail.com> wrote:
> > >
> > > > Oh, so that's what "non-binding" means in vote threads
> > > > Those threads make a lot more sense now, thanks for the heads-up =)
> > > >
> > > > On Thu, Sep 8, 2022 at 12:31 PM David Li <lidav...@apache.org> wrote:
> > > >
> > > > > Non-binding votes are always welcome and encouraged! Was just trying
> > to
> > > > > make sure we have the minimum 3 binding votes here but it turns out I
> > > > can't
> > > > > count and I make three.
> > > > >
> > > > > On Thu, Sep 8, 2022, at 12:14, Gavin Ray wrote:
> > > > > > If non-PMC can vote, I'll also give a huge +1
> > > > > >
> > > > > > On Thu, Sep 8, 2022 at 11:34 AM Matthew Topol
> > > > > <m...@voltrondata.com.invalid>
> > > > > > wrote:
> > > > > >
> > > > > >> I'm not PMC but i'll give a +1 (non-binding) vote. I like the idea
> > > of
> > > > > >> integrating Substrait plans into Flight SQL if possible and it
> > > aligns
> > > > > >> with the arrow-adbc work.
> > > > > >>
> > > > > >> On Thu, Sep 8 2022 at 11:31:59 AM -0400, David Li <
> > > > lidav...@apache.org>
> > > > > >> wrote:
> > > > > >> > My vote: +1 (binding)
> > > > > >> >
> > > > > >> > Are any other PMC members available to take a look?
> > > > > >> >
> > > > > >> > On Wed, Sep 7, 2022, at 09:18, Antoine Pitrou wrote:
> > > > > >> >>  Fair enough. For the record, my main concern with ad-hoc
> > > > conventions
> > > > > >> >>  such as "number of milliseconds expressed as an integer" is
> > the
> > > > poor
> > > > > >> >>  usability and the potential for confusion (not to mention that
> > > > > >> >> sometimes
> > > > > >> >>  the need for a higher precision can lead to add another set of
> > > > > >> >> APIs, but
> > > > > >> >>  that's unlikely to be the case here :-)).
> > > > > >> >>
> > > > > >> >>  Regards
> > > > > >> >>
> > > > > >> >>  Antoine.
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>  Le 07/09/2022 à 14:21, David Li a écrit :
> > > > > >> >>>  Absent further comments on this I would rather avoid adding a
> > > > > >> >>> potentially breaking (even if likely compatible) change to the
> > > > > >> >>> schema of this endpoint, if that's acceptable. I don't think a
> > > > > >> >>> millisecond timeout is all too different from floating-point
> > > > > >> >>> seconds (especially at the scale of network RPCs).
> > > > > >> >>>
> > > > > >> >>>  On Tue, Sep 6, 2022, at 12:44, David Li wrote:
> > > > > >> >>>>  We could add a new type code to the union. Presumably
> > > consumers
> > > > > >> >>>> would
> > > > > >> >>>>  just error on or ignore such values (the libraries just hand
> > > the
> > > > > >> >>>> Arrow
> > > > > >> >>>>  array to the application, so it's up to the application what
> > > to
> > > > > >> >>>> do with
> > > > > >> >>>>  an unknown type code). (And for a new consumer talking to an
> > > old
> > > > > >> >>>>  server, the new type code would just never come up, so the
> > > only
> > > > > >> >>>> issue
> > > > > >> >>>>  would be if it strictly validates the returned schema.)
> > > > > >> >>>>
> > > > > >> >>>>  If there's support, I can make this revision as well.
> > > > > >> >>>>
> > > > > >> >>>>  On Tue, Sep 6, 2022, at 12:37, Antoine Pitrou wrote:
> > > > > >> >>>>>  Le 06/09/2022 à 17:21, David Li a écrit :
> > > > > >> >>>>>>  Thanks Antoine!
> > > > > >> >>>>>>
> > > > > >> >>>>>>  I've updated the PR (except for the comment about timeout
> > > > > >> >>>>>> units, since SqlInfo values can't be doubles/floats unless
> > we
> > > > > >> >>>>>> change the schema there)
> > > > > >> >>>>>
> > > > > >> >>>>>  Can we change the schema in a backwards-compatible way?
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> > >
> > > --
> > > thanks
> > > ashish
> > >
> >

Reply via email to