Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 25 Dec 2023 09:52:53 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>,
	David Rowley <dgrowleyml@gmail.com>, exclusion@gmail.com,
	pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
Message-ID: <ZYjSZZu1UGUlXWXa@paquier.xyz>
References: <18240-c5da758d7dc1ecf0@postgresql.org>
 <ZXbi3xo7QhQIe1YN@paquier.xyz>
 <2171714.1702307153@sss.pgh.pa.us>
 <ZXgh74Ykj3iWvXKr@paquier.xyz>
 <CAApHDvrBLa=gQ0tCg8727RaZXWDg1sDvFJ2+-DVy5SC=NSSKkg@mail.gmail.com>
 <2433182.1702391878@sss.pgh.pa.us>
 <ZX1rmhppwgaczYQ7@paquier.xyz>
 <3453263.1702739958@sss.pgh.pa.us>
 <ecdf4a19-e97d-42c8-be45-fb5a46166160@postgresql.org>
 <1673413.1703442075@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="zpsp3DOeX6ihaF7i"
Content-Disposition: inline
In-Reply-To: <1673413.1703442075@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/ZYjSZZu1UGUlXWXa%40paquier.xyz>
Precedence: bulk


--zpsp3DOeX6ihaF7i
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Dec 24, 2023 at 01:21:15PM -0500, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> I'm of the strong opinion that we should get rid of money. I personally=
=20
>> haven't encountered it in the wild -- I'm sure it's there, but it seems=
=20
>> limited -- and most apps that seriously deal with money will either user=
=20
>> either "numeric" or an integer-based type.
>=20
> 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.

Yeah, that's hard to say.  Perhaps it would a good idea to ask more
widely how much people have been relying on that and how large these
data sets are.  Another thing that we could attempt is doing something
about the the table rewrites on type changes to require an EOL.  Like
more CONCURRENTLY flavors in ALTER TABLE?

>> I am sensitive to the upgrade piece, as we don't want someone relying on=
=20
>> that behavior to be indefinitely stuck. But perhaps part of the=20
>> deprecation plan is to just keep the casts around[1] for a few releases,=
=20
>> without exposing the type, and prevent new creations of the type?
>=20
> 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.

At least the infra to be able to achieve that should be here.
--
Michael

--zpsp3DOeX6ihaF7i
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmWI0mUACgkQnvQgOdby
QH3iqQ//ewI8asVG8+cNDIMm/ipEaReQIYnhAW0rLAIxo8UvqipNX6LdddPJm6/q
xTDHC0jYi/NESrMMo8RRx9LcdH+oh0v/OJRhMmeWi94bPVZn+JFNt77au6Ftbqb6
QoPjuGlCls8pjz4ONQnE19EYLacTUCiZvou8WLIYKN8eoltlR+REf8wiPwKbIp8m
P2jTCVRvPCf+NF3pTZcNice3iujXXq+ddswIsOtkgAIJr9DBM0/LuzrSYL1WSNKj
BPvC5lFHG4e7O2dFgLvHWUxvlzPdRfuvj6oyzDkoy5VTa5I52n9LL1I5Axe2ygvb
GLdybhykQ4cepWM6HB7txez4OjW9PsX3Uh+iSA2GXKK83O1ls1J0qzfGu86PuDHq
GBI4/IzLxMt8lleeNeETgvBRtXiB2tuE7w8oBYKUhZB7vlEY7E9UYVgchcWKHVlP
azdbxelZsyeRe6iXIQvfgAyCkR04zqVEVsMxU7sF6ZL6bluKFV7EbI7q46wTgnM2
rgJ2DxpTyCd6SCSfnhJd8LbOLuYR39yXQrsL1VnQXrFEahXOoMSC9KX1INMPhpmF
2qnLkfdsOQGaJWU1rMA4eVs3owbS/dZTm3A+U0QbYYWOFV45HbAf9+PAQdNH5rTk
k09bz5/gT9mn7S0QmL+fx0rXk/nqXKbT0TuDzR7InNxN5znmRQ0=
=03L6
-----END PGP SIGNATURE-----

--zpsp3DOeX6ihaF7i--