Horton

abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: pgsql-hackers@postgresql.org
Date: 2025-10-17T16:54:52Z
Lists: pgsql-hackers 
My recent commit 688dc62, which was back-patched to v18, has made the
abi-compliance-check on buildfarm member baza unhappy:

	https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=baza&dt=2025-10-17%2013%3A11%3A11

Specifically, I replaced two functions related to lookups/privilege checks
for the new stats stuff in v18 with RangeVarGetRelidExtended().  FWIW I did
check codesearch.debian.net and GitHub for any third-party usage of these
functions before committing, and I found none.  Also, these functions are
only present in exactly one release (18.0).

My thinking was that this ABI breakage was probably fine, as I don't think
we really intended for these functions to be used elsewhere.  However,
since we have a buildfarm failure, I thought it best to broadcast my
thought process.  While I judged back-patching worth the risk, I could live
with reverting the change on v18 if anyone is concerned.

-- 
nathan

Commits

  1. Add commit 24f6c1bd4 to v17 .abi-compliance-history.

  2. Add .abi-compliance-history to back-branches.

  3. Add reminder to create .abi-compliance-history.

  4. Update .abi-compliance-history file.

  5. Add .abi-compliance-history to v18 branch.

  6. Fix thinko in commit 7d129ba54.

  7. Fix lookups in pg_{clear,restore}_{attribute,relation}_stats().

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