Date: Fri, 17 Oct 2025 14:11:10 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, david@justatheory.com,
	Andrew Dunstan <andrew@dunslane.net>
Subject: Re: abi-compliance-check failure due to recent changes to
 pg_{clear,restore}_{attribute,relation}_stats()
Message-ID: <aPKUzk2xFhZBbWmz@nathan>
References: <aPJ03E2itovDBcKX@nathan>
 <1713509.1760721320@sss.pgh.pa.us>
 <aPKFmL8VjOKNVLcw@nathan>
 <1723302.1760726712@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="ElAiJVQmFZUs29PJ"
Content-Disposition: inline
In-Reply-To: <1723302.1760726712@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/aPKUzk2xFhZBbWmz%40nathan>
Precedence: bulk


--ElAiJVQmFZUs29PJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Oct 17, 2025 at 02:45:12PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> On Fri, Oct 17, 2025 at 01:15:20PM -0400, Tom Lane wrote:
>>> FWIW, I favor the approach of having an in-tree, per-branch file
>>> containing the commit hash of a commit that is the current ABI
>>> reference for that branch.
> 
>> I'm new to the topic, but IMHO the per-branch file approach is by far the
>> best approach.  Not only is it much more flexible, but we could even use it
>> as a centralized list of ABI breaks for a given branch with justification
>> for each.  I can't think of any strong advantages of keeping this stuff in
>> git metadata.  git itself uses a file for blame.ignoreRevsFile...
> 
> Good idea.  We'd have to allow comments in the file, but that's
> probably a good thing anyway.

I've attached a first try.  You'll notice that I have borrowed heavily from
.git-blame-ignore-revs.  Some other things that might be worthwhile:

* Add commentary about when this file is needed (i.e., after the .0).
* Add instructions for creating file on new stable branch to
RELEASE_CHANGES.
* Adjust format for readability.  It is a bit comment-heavy at the moment.

Anything else?  I suppose this idea is entirely dependent on the
maintainers of the abi-compliance-check code to adapt to it, so we'll need
buy-in from them, too.

-- 
nathan

--ElAiJVQmFZUs29PJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
	filename=v1-0001-Add-.abi-compliance-history-file.patch

From 4564f78bb861e2862cc037a95b517c38b38d06b6 Mon Sep 17 00:00:00 2001
From: Nathan Bossart <nathan@postgresql.org>
Date: Fri, 17 Oct 2025 14:03:50 -0500
Subject: [PATCH v1 1/1] Add .abi-compliance-history file.

---
 .abi-compliance-history | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 .abi-compliance-history

diff --git a/.abi-compliance-history b/.abi-compliance-history
new file mode 100644
index 00000000000..0148d0fcda4
--- /dev/null
+++ b/.abi-compliance-history
@@ -0,0 +1,19 @@
+# This file lists commits on the REL_18_STABLE branch that break ABI
+# compatibility in ways that have been deemed acceptable (e.g., removing an
+# extern function with no third-party uses).  The primary intent of this file
+# is to placate the ABI compliance checks on the buildfarm, but it also serves
+# as a central location to document the justification for each.
+#
+# Add new entries by adding the output of the following to the top of the file:
+#
+# $ git log --pretty=format:"%H # %cd%n# %s" $ABIBREAKGITHASH -1 --date=iso
+#
+# Be sure to include additional context in a comment below the entry.
+
+c8af5019bee5c57502db830f8005a01cba60fee0 # 2025-10-15 12:47:33 -0500
+# Fix lookups in pg_{clear,restore}_{attribute,relation}_stats().
+#
+# This commit replaced two functions related to lookups/privilege checks for
+# the new stats stuff in v18 with RangeVarGetRelidExtended().  These functions
+# were not intended for use elsewhere, exist in exactly one release (18.0), and
+# do not have any known third-party callers.
-- 
2.39.5 (Apple Git-154)


--ElAiJVQmFZUs29PJ--