On Fri, 24 Jul 2026 at 06:34, John Naylor <[email protected]> wrote: > > On Thu, Jul 23, 2026 at 12:26 PM Zsolt Parragi > <[email protected]> wrote: > > I think this commit caused a regression with OIDs >= 2**31: > > > > CREATE TABLE t (o oid); > > INSERT INTO t VALUES ('2147483648'); > > SELECT o FROM t UNION ALL SELECT '3000000000'::oid ORDER BY 1; > > Thanks for reporting! Here's the problem: An oid from a heap tuple > goes through fetch_att(), which uses Int32GetDatum for all 4-byte > byval types, which sign-extends. An oid produced by oidin() goes > through ObjectIdGetDatum, which zero-extends. That didn't matter for > btoidfastcmp(), since it compared via DatumGetObjectId(x). > > I think the easiest fix is to revert the oid part of commit 51cd5d6f0, > leaving behind the int2 and oid8 parts. The asymmetry between the 2 > oid types would look odd, though, so that would require an explanatory > comment.
I didn't see it mentioned, but just for the archives' sake, did you rule out adding a dedicated uint32 comparator function? Or is there some other reason this can't be done due to the radix sort code? David
