Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rHnME-004Htp-ES for pgsql-bugs@arkaria.postgresql.org; Mon, 25 Dec 2023 15:59:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rHnMA-003YOP-2J for pgsql-bugs@arkaria.postgresql.org; Mon, 25 Dec 2023 15:59:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rHnM9-003YOH-PV for pgsql-bugs@lists.postgresql.org; Mon, 25 Dec 2023 15:59:05 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rHnM6-00Dq8T-Pg for pgsql-bugs@lists.postgresql.org; Mon, 25 Dec 2023 15:59:04 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 3BPFwxw51851212; Mon, 25 Dec 2023 10:58:59 -0500 From: Tom Lane To: Michael Paquier cc: "Jonathan S. Katz" , David Rowley , exclusion@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18240: Undefined behaviour in cash_mul_flt8() and friends In-reply-to: References: <2171714.1702307153@sss.pgh.pa.us> <2433182.1702391878@sss.pgh.pa.us> <3453263.1702739958@sss.pgh.pa.us> <1673413.1703442075@sss.pgh.pa.us> Comments: In-reply-to Michael Paquier message dated "Mon, 25 Dec 2023 18:57:57 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1851210.1703519939.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Dec 2023 10:58:59 -0500 Message-ID: <1851211.1703519939@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Paquier writes: > Looking at that, I can see that Peter has added a few tests to test > the predictability of plans generated with non-hashable types, and > that these are based on money. See 6dd8b0080787. > One possible pick to replace money for these tests is tsvector, that > cannot be hashed and has an equality operator. Perhaps these had > better be replaced anyway? Hm. A quick check in pg_opclass shows that these are the types that currently have btree but not hash opclasses: # select ob.opcintype::regtype from (select * from pg_opclass where opcmet= hod =3D 403) ob left join (select * from pg_opclass where opcmethod =3D 405) oh using(opci= ntype) where oh.opcintype is null; opcintype = ------------- bit bit varying money tsvector tsquery (5 rows) 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. Or we could build a for-test-purposes-only datatype, but that could require a lot of scaffolding work. regards, tom lane