| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, John Naylor <johncnaylorls(at)gmail(dot)com> |
| Subject: | Re: btoidsortsupport issue |
| Date: | 2026-08-09 21:06:54 |
| Message-ID: | CAApHDvoZRXCYo-Lr4U8--EtF8v=yf03UWeUkEkYgGjH7Mkz6xQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 10 Aug 2026 at 08:19, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> btoidsortsupport() uses ssup_datum_unsigned_cmp() at that commit,
> which compares all 64 bits of each Datum. The test case shows that the
> same oid value can reach the comparator with the extraneous bits
> filled two different ways. Tuple deformation sign-extends every 4-byte
> pass-by-value attribute (see fetch_att() and friends), whereas
> ObjectIdGetDatum() zero-extends instead. This inconsistency makes
> their datums incompatible for ssup_datum_unsigned_cmp's purposes,
> leading to wrong answers in certain narrow cases.
This seems to be a duplicate of [1].
David
[1] https://postgr.es/m/CA+fm-RMyLC94NfrxCh273+dKs44U0ZJjRczznvzvgw=KtpPNVw@mail.gmail.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-08-09 21:17:50 | Re: btoidsortsupport issue |
| Previous Message | Peter Geoghegan | 2026-08-09 20:19:02 | btoidsortsupport issue |