Horton

Re: Pathify RHS unique-ification for semijoin planning

Richard Guo <guofenglinux@gmail.com>

View thread
From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-13T02:17:52Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Simplify relation_has_unique_index_for()

  2. Pathify RHS unique-ification for semijoin planning

  3. Convert varatt.h access macros to static inline functions.

  4. Re-export a few of createplan.c's make_xxx() functions.

On Wed, Aug 13, 2025 at 1:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> > No review, but apparently "uniquify" is more widely accepted than
> > "uniqueify".

> Personally I'd write "unique-ify", seeing that neither of the forms
> without the dash are considered good English.  Of course, if you
> need to make identifiers out of this, that solution doesn't work;
> but you could just avoid the construction --- say, "make_path_unique"
> rather than "uniquify_path".

Some 'git grep' work shows that, currently on master, we commonly use
the form "unique-ify" (with the dash) and its variants, such as:
unique-ify, unique-ified, unique-ification, and unique-ifying.

$ git grep -in 'unique-if' | wc -l
50

There is one instance of the form "uniquify":
planner.c:5107: * check).  We can uniquify these tuples simply by just taking

And one instance of "uniqueify" (without the dash):
jsonb_util.c:65:static void uniqueifyJsonbObject()

Given this, I'd prefer to stick with "unique-ify", for consistency
with the majority usage in the codebase.

In this patch, the only instance that doesn't follow the "unique-ify"
form is the macro IS_UNIQUEIFIED_REL, as dashes are not allowed in C
identifiers.  Maybe a better alternative is IS_RELATION_UNIQUE?  Any
suggestions?

Thanks
Richard