cuDF has decimal32/decimal64 [1]. Would a canonical extension type [2] be appropriate here? I think that's come up as a solution before.
[1]: https://docs.rapids.ai/api/cudf/stable/user_guide/data-types/ [2]: https://arrow.apache.org/docs/format/CanonicalExtensions.html On Thu, Nov 9, 2023, at 11:56, Antoine Pitrou wrote: > Or they could trivially use a int64 column for that, since the scale is > fixed anyway, and you're probably not going to multiply money values > together. > > > Le 09/11/2023 à 17:54, Curt Hagenlocher a écrit : >> If Arrow had a decimal64 type, someone could choose to use that for a >> PostgreSQL money column knowing that there are edge cases where they may >> get an undesired result. >> >> On Thu, Nov 9, 2023 at 8:42 AM Antoine Pitrou <anto...@python.org> wrote: >> >>> >>> Le 09/11/2023 à 17:23, Curt Hagenlocher a écrit : >>>> Or more succinctly, >>>> "111,111,111,111,111.1111" will fit into a decimal64; would you prevent >>> it >>>> from being stored in one so that you can describe the column as >>>> "decimal(18, 4)"? >>> >>> That's what we do for other decimal types, see PyArrow below: >>> ``` >>> >>> pa.array([111_111_111_111_111_1111]).cast(pa.decimal128(18, 0)) >>> Traceback (most recent call last): >>> [...] >>> ArrowInvalid: Precision is not great enough for the result. It should be >>> at least 19 >>> ``` >>> >>> >>
