The vote passes with 5 binding votes and 7 non-binding votes. Thanks all!

I will rebase the PR and ensure CI passes before merging.

On Fri, Sep 9, 2022, at 16:14, Wes McKinney wrote:
> +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