| 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
| 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 |