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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Jonathan S. Katz" <jkatz@postgresql.org>
Cc: Michael Paquier <michael@paquier.xyz>, David Rowley <dgrowleyml@gmail.com>, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2023-12-24T18:21:15Z
Lists: pgsql-bugs
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> 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.

Yeah, maybe we should just do it.  I was pleasantly surprised by how
little push-back we got from nuking the 32-bit datetime types a few
releases ago; perhaps this one would likewise not have much of a
constituency.

> 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?

I don't really see a way to do that, especially not if we don't want
to put a large amount of effort into it.  We can certainly make
pg_upgrade reject "money" columns, and tell people they need to
rewrite those before they upgrade not after.

			regards, tom lane



Commits

  1. Add overflow checks to money type.

  2. Reduce dependency to money data type in main regression test suite