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

Nathan Bossart <nathandbossart(at)gmail(dot)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