Re: Do we still need gen_node_support.pl's nodetag ABI stability check?

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Date: 2026-04-15T18:13:46Z
Lists: pgsql-hackers

Attachments

I wrote:
> We're still a couple months away from cutting the REL_19_STABLE
> branch, but I was contemplating that just now, and it occurred to me
> to wonder whether we still need gen_node_support.pl's single-purpose
> ABI check (cf commit eea9fa9b2) now that we have buildfarm animals
> running general-purpose ABI stability checks.

> On the one hand, there's much to be said for belt-and-suspenders-too
> safety checks.  On the other hand, updating gen_node_support.pl is
> an extra manual step while creating a branch, so it's easy to forget
> or get wrong.  It's also not very clear why this particular sort
> of ABI break in a stable branch is any worse than other hazards.

> I'm not really set either way, but my first thought is to drop
> the special mechanism.

Hearing no objections, I went ahead and wrote a patch for that.
Doing that reminded me that it's a really incomplete check anyway,
as it only verifies that the last auto-assigned NodeTag number
hasn't changed.  Re-ordering earlier entries, for example, would
not get detected.  So even on its own terms it's little more than
a stopgap; the buildfarm's libabigail checks are far more thorough.

Barring objections, I'll push this soon.

			regards, tom lane

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove gen_node_support.pl's ad-hoc ABI stability check.

  2. Add defenses against unexpected changes in the NodeTag enum list.