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

On Fri, 24 Jul 2026 at 06:34, John Naylor <johncnaylorls(at)gmail(dot)com> wrote:
>
> 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.

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