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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-16 09:19:22
Message-ID: ZX1rmhppwgaczYQ7@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Dec 12, 2023 at 09:37:58AM -0500, Tom Lane wrote:
> ... I doubt that a contrib module would solve the problem for people
> who can't afford a rewrite. pg_upgrade requires that datatype OIDs
> stay the same, which is something I don't believe a contrib module
> could manage. We've run into that before if memory serves. Is it
> time to do something about that? 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?

You mean with an integration in binary dumps? I don't see why it
would not work and this facility may prove to be useful for
out-of-core extension, assuming that this can be made transparent
based on some new .control properties on the upgrade cluster, I
guess..

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.
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-12-16 15:19:18 Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
Previous Message Tom Lane 2023-12-15 15:43:03 Re: BUG #18247: Integer overflow leads to negative width