Re: [PATCH] Use ssup_datum_*_cmp for int2, oid, and oid8 sort support

On Thu, Jul 23, 2026 at 12:26 PM Zsolt Parragi
<zsolt(dot)parragi(at)percona(dot)com> 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