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?
