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

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Baji Shaik <baji(dot)pgdev(at)gmail(dot)com>
Subject: Re: [PATCH] Use ssup_datum_*_cmp for int2, oid, and oid8 sort support
Date: 2026-08-06 10:46:39
Message-ID: CANWCAZaim3y2Fh1Z3eEkur6bZLYqRq4CxF1tE3Bu66-tgZJhAw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 6, 2026 at 3:29 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > On Fri, Jul 24, 2026 at 7:04 PM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:

> > + /*
> > + * We cannot use ssup_datum_unsigned_cmp here, since the upper half of a
> > + * Datum containing a 32-bit type is not reliably zero-extended.
> > + */
> >
> > ...by mentioning 32-bit the difference from oid8 should be obvious, I hope.
>
> Is it ever necessary to have that as a comment? Maybe it'd be better
> to rename ssup_datum_unsigned_cmp to ssup_datum_uint64_cmp. It just
> doesn't seem questionable why you'd use the 64-bit version for a
> 32-bit type with those names.

Yeah, self-documenting code is best. I'll plan on pushing both the
rename and v2 early next week. Thanks for looking!

--
John Naylor
Amazon Web Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ewan Young 2026-08-06 10:47:25 RANGE partition pruning can still exclude the default partition
Previous Message John Naylor 2026-08-06 10:34:24 Re: arrays over initdb-created types are broken after pg_upgrade