Le 10/07/2026 à 11:27, Divjot Arora via dev a écrit :
Yeah, well, regardless, this is derailing the discussion quite a bit.
This proposal is not about extending DBP to FLBA. Can we keep it on topic?
Agreed, let's keep this discussion focused to extended-precision
timestamps. We can have separate discussions on encodings..
And conversely, I do not see what we get out of mandating FLBA<12>. :-)
FLBA<N> works, but I would be concerned about added complexity on the
reader side as I assume engines will want to use compact data types to
represent timestamps as much as possible, so they'd have to manage
different data types for different values of N.
Being able to use compact data types is a good thing, no? :-)
The good news is that some readers already have similar code for reading
Decimals from arbitrary FLBA<N>. For example, Parquet C++ can read
Decimal-annotated FLBA<N> into Arrow Decimal128 or Decimal256, depending
on the advertised precision.
(and the code to do that is reasonably simple: you're really
sign-extending from one integer width to another)
Regards
Antoine.
