I think there are two main questions to answer here. 1. Which creates option creates less implementation complexity:
* I think today the spec maps encodings to physical types (logical types are not considered) and at least the implementations I spot checked do not seem to pass through logical metadata to determine possible encodings. * Having a new physical would not require API changes for default encoding/decoding. In both cases if we wanted to define things like DELTA_BINARY_PACKED custom code would be needed in some languages. 2. Is one more favorable than the other from a compatibility concern? * It seems using FLBA for wider integer types is less likely to cause compatibility issues when reading (it's not clear how many readers would gracefully handle parsing metadata with an unknown physical type. This tends to make me lean in favor of FLBA but I think we need to do some PoCs to see how much an implementation would actually need to change to accommodate encodings by logical type (and to verify behavior of readers on new physical types). Cheers, Micah On Wed, Jul 9, 2025 at 12:06 PM Antoine Pitrou <anto...@python.org> wrote: > On Wed, 9 Jul 2025 16:24:58 +0100 > Raphael Taylor-Davies > <r.taylordav...@googlemail.com.INVALID> > wrote: > > > DELTA_BINARY_PACKED to be used on FLBA(16) if > > > that's a concern. > > I don't think you can as DELTA_BINARY_PACKED requires arithmetic > > operations to be well-defined for the type. > > One could define it for > > FLBA(16) in a way that assumes the contents to be Int128 but I think > > that would be a little unusual. > > Unusual, but well-defined anyway :) > > Regards > > Antoine. > > >
