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

Hackers,

Adding Mankirat, who developed the ABI checker for his GSoC project.

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

Is the idea that the ABI checker just has to scan the first non-comment line that starts with a commit identifier (SHA or tag)? Example from your patch:

```
# 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)
```

Seems totally do-able, though I don’t know what that `(Apple Git-154)` bit is doing at the end. I presume it would list the history of changes in reverse chronological order, yes?

If there is a tag _AFTER_ the listed SHA, should we prefer that tag as the baseline?

Best,

David