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?
