I agree that physical type alias has some obvious drawbacks. I imagine physical type alias is a pure informative attribute of a physical type to help define supported encodings, column order, arithmetic operations, etc.
On Sat, Jul 26, 2025 at 7:02 AM Ryan Blue <rdb...@gmail.com> wrote: > I don't think that physical type aliases are a good solution. That would > limit our ability to add a real INT128 type in the future because we would > have to differentiate between INT128 as an alias or INT128 with its own > encoding. A physical type alias would cause problems, but this is what > logical types are for. We could add an INT128 logical type... but then we > don't really need one if we want it just to support a different logical > type like INTERVAL. > > On Fri, Jul 25, 2025 at 9:34 AM Gang Wu <ust...@gmail.com> wrote: > > > 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. > > > > > > > > > > > > > > > > > >
