Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends
Date
Msg-id ZZ9AdxEEwHD8CWJ5@paquier.xyz
Whole thread Raw
In response to Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends  ("Jonathan S. Katz" <jkatz@postgresql.org>)
List pgsql-bugs
On Mon, Dec 25, 2023 at 10:58:59AM -0500, Tom Lane wrote:
> I'm a little nervous about using tsvector or tsquery, as it seems
> pretty plausible that somebody would get around to making hash
> support for them someday.  Perhaps the same argument could be made
> about bit or varbit, but I'd bet a lot less on that happening,
> as those are backwater-ish types (not even in the standard
> anymore, IIRC).  So I'd think about using one of those.

Okay, I've used varbit then.

> Or we could build a for-test-purposes-only datatype, but that
> could require a lot of scaffolding work.

It took me some time to come back to this thread, apologies for the
delay.

I have been looking at all that, and finished for now with the
attached patch that removes the dependency to "money" in the main
regression test suite in all the relevant places without losing
coverage, switching these to use varbit (well, mostly):
- Tests for hashing and hash-based plans (6dd8b0080787).
- A set of tests in rules used money historically but these can be
switched to numeric.
- Two tests in stats_ext relied on cash_words() to generate different
strings, but the same variance can be achieved without it.
- One test in create_table relied on money as its cast is not
immutable.  Here it is possible to use a timestamptz to achieve the
same, with something like to_date() to force a function execution
when defining a partition boundary for one of the partitions (from
7c079d7417a8).

With this patch, the tests related to money that remain are for
type_sanity, window.sql and of course money which are all related to
the data type so they could be wiped out once the type is itself
removed.

While looking at the whole picture, an issue with the direct removal
of money is how we should handle btree_gin and btree_gist which have
operators based on money.  We try to keep things compatible at
run-time, but could this be worth a hard break in these modules,
dropping the older sql scripts used in the modules if we don't have
access to money anymore at runtime?  These are not popular modules..
Any thoughts about that?

For now, please find attached a patch to adjust the regression tests
to depend less on money, which does not depend on the type removal.

Comments are welcome.
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Noah Misch
Date:
Subject: Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune()
Next
From: Alexander Lakhin
Date:
Subject: Re: BUG #17798: Incorrect memory access occurs when using BEFORE ROW UPDATE trigger