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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, David Rowley <dgrowleyml(at)gmail(dot)com>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
Date: 2023-12-24 18:21:15
Message-ID: 1673413.1703442075@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Jonathan S. Katz" <jkatz(at)postgresql(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alexander Korotkov 2023-12-24 23:37:50 Re: BUG #18187: Unexpected error: "variable not found in subplan target lists" triggered by JOIN
Previous Message Jonathan S. Katz 2023-12-24 17:16:31 Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends