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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> wrote:
> >
> > > On Wed, 9 Jul 2025 16:24:58 +0100
> > > Raphael Taylor-Davies
> > > <[email protected]>
> > > 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.
> > >
> > >
> > >
> >
>

Reply via email to