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

Nathan Bossart <nathandbossart@gmail.com> writes:
> 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.

I don't have a problem with the change you made.  I do have a problem
with baza having spun up this check before we settled on a way to
manage it.  AFAIK we don't have any process by which we can decide
that a reported ABI change is acceptable and then clear the failure.
There was some discussion of how to control it [1], but nothing's been
done yet.

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.  If the file doesn't exist (which it
wouldn't in master, and probably not in recently-forked branches),
skip ABI checking.  I think this is superior to the discussed
alternative of depending on git tags, because files are easy to
change or remove, while tags are not.  In particular, I think it'd
likely be impossible to make the ABI reference point go backwards
if we use tags.  Maybe that's not a case we'd ever need, but I'm
unconvinced of that.

            regards, tom lane

[1] https://www.postgresql.org/message-id/438875.1752433368%40sss.pgh.pa.us