Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends

On 12/16/23 10:19 AM, Tom Lane wrote:
> Michael Paquier <michael(at)paquier(dot)xyz> writes:
>> On Tue, Dec 12, 2023 at 09:37:58AM -0500, Tom Lane wrote:
>>> ... Perhaps we could allow extension
>>> modules to use binary_upgrade_set_next_pg_type_oid, and then somehow
>>> reserve the money and _money OIDs forever?
>
>> Now, I am not sure that we're making users a favor in keeping around a
>> data type that's kind of obsolete these days, particularly when all of
>> them basically require handling of fractional cents when doing serious
>> calculations. That's a trap in disguise, even if tying data to a
>> locale for the unit sounds appealing for some applications.
>
> Yeah, I wouldn't propose this if money were the only type we were
> thinking of getting rid of; likely not worth the trouble. But I've
> got one eye on the geometric types as well --- I think it would be
> great all around if we could kick those out of the core distribution
> and let them be maintained independently. But I fear we can't do that
> without some method whereby pg_upgrade is still possible across the
> change.

"money" poses a bit more risk than the geometric types (I do want to
come back to geometric types later), and it'd be good if we could make
some headway on removing it. Just this past week I came across a case
where "money" was being discussed as being valid, and had to give the
"it's kinda, sorta deprecated" talk.

I'm of the strong opinion that we should get rid of money. I personally
haven't encountered it in the wild -- I'm sure it's there, but it seems
limited -- and most apps that seriously deal with money will either user
either "numeric" or an integer-based type.

I am sensitive to the upgrade piece, as we don't want someone relying on
that behavior to be indefinitely stuck. But perhaps part of the
deprecation plan is to just keep the casts around[1] for a few releases,
without exposing the type, and prevent new creations of the type? We do
state that "A money value can be cast to numeric without loss of
precision"[1], but I do agree with the concerns on a pg_upgrade
operation being stuck on a costly rewrite operation.

Would it make sense to block an upgrade via pg_upgrade if we detect a
money type unless it's rewritten to a different type? Users should still
be able to user other upgrades methods if need be, and handle the
rewrite during that time.

Jonathan

[1] https://www.postgresql.org/docs/current/datatype-money.html