+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
