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. -- John Naylor Amazon Web Services
