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?
