+1 (binding) Format change looks good to me. I haven't reviewed the individual implementations.
Thanks David for leading this. El mié, 24 jul 2024 a las 10:51, Joris Van den Bossche (<jorisvandenboss...@gmail.com>) escribió: > > +1 (binding) > > On Wed, 24 Jul 2024 at 07:34, David Li <lidav...@apache.org> wrote: > > > > Hello, > > > > I'd like to propose the 'Opaque' canonical extension type. Prior discussion > > can be found at [1] and the proposal and implementations for C++, Go, Java, > > and Python can be found at [2]. The proposal is additionally reproduced > > below. > > > > The vote will be open for at least 72 hours. > > > > [ ] +1 Accept this proposal > > [ ] +0 > > [ ] -1 Do not accept this proposal because... > > > > [1]: https://lists.apache.org/thread/8d5ldl5cb7mms21rd15lhpfrv4j9no4n > > [2]: https://github.com/apache/arrow/pull/41823 > > > > --- > > > > Opaque represents a type that an Arrow-based system received from an > > external > > (often non-Arrow) system, but that it cannot interpret. In this case, it > > can > > pass on Opaque to its clients to at least show that a field exists and > > preserve metadata about the type from the other system. > > > > Extension parameters: > > > > * Extension name: ``arrow.opaque``. > > > > * The storage type of this extension is any type. If there is no underlying > > data, the storage type should be Null. > > > > * Extension type parameters: > > > > * **type_name** = the name of the unknown type in the external system. > > * **vendor_name** = the name of the external system. > > > > * Description of the serialization: > > > > A valid JSON object containing the parameters as fields. In the future, > > additional fields may be added, but all fields current and future are > > never > > required to interpret the array. > > > > Developers **should not** attempt to enable public semantic > > interoperability > > of Opaque by canonicalizing specific values of these parameters.
