Just curious if we can introduce physical type aliases like INT128 = FLBA(16). Perhaps we can also add aliases like INT8 = FLBA(1) and INT16 = FLBA(2) though they are less attractive. TBH, I think Float16 should be a type alias to FLBA(2) rather than a logical type.
The type alias may be helpful because we can limit DELTA_BINARY_PACKED to these type aliases rather than all FLBA types. On Sat, Jul 12, 2025 at 3:07 AM Micah Kornfield <emkornfi...@gmail.com> wrote: > 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. > > > > > > >