>From a Rust perspective, I don't see any significant fundamental difference between Fixed Length Binary(16) and an Int128. Therefore I also favor using the existing type rather than adding a new one.
The fact we already have optimized readers/writers for Fixed Length Binary means that it would likely be less work to reuse the existing types rather than support a new i128 type. One potential issue with using Fixed Length Binary would be that it is not consistent with the existing physical types (Int32/Int64/Float/Double, etc) but I don't see that as a deal breaker Andrew On Wed, Jul 9, 2025 at 4:11 AM Antoine Pitrou <anto...@python.org> wrote: > > As someone who's primarily involved in the Parquet C++ implementation, > I definitely agree with this. > > Regards > > Antoine. > > > On Tue, 8 Jul 2025 19:36:33 +0200 > Gábor Szádovszky <ga...@apache.org> wrote: > > The potential introduction of the primitive type INT128 came up related > to > > the Interval type discussions. I think it is an independent topic, so let > > me start a new thread about it. > > > > Maybe, I'm too Java oriented but I cannot see much difference between > > FLBA[16] and a new primitive containing 16 bytes. We can define any byte > > ordering for a specific logical type on top of FLBA[16] as well as any > > value ordering related to that type. We may also easily extend int > specific > > encodings to FLBA, then it is up to the implementation to choose that > > encoding for specific logical types. > > > > From implementation point of view, in Java, since we don't have a 16 byte > > primitive, we would represent INT128 the same way as we do in the case of > > FLBA[16]. > > Other languages choose whatever in-memory representation they want to > > handle FLBA[16] or especially the related logical type. > > > > What do you think? > > > > Cheers, > > Gabor > > > > > >
