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

"David E. Wheeler" <david(at)justatheory(dot)com> writes:
> On Oct 29, 2025, at 19:52, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'm asking to remove complexity, not add more. The buildfarm client
>> should not be checking either branch names or git tags to control
>> this, when we have a perfectly good convention about the existence
>> of .abi-compliance-history to control it.

> We can remove the branch check, of course, but then you would have to maintain .abi-compliance-history in master, no?

No; my proposal was "don't run the ABI check unless the branch has
a .abi-compliance-history file". master would normally not contain
such a file, thus no check. As I was just discussing with Bruce,
we could put one there for awhile if we wanted to run ABI checks in
advance of forking a stable branch.

The reason I'm so allergic to having any of these decisions made on
the buildfarm-client side is years of herding cats^W^W trying to get
buildfarm owners to update their script versions and/or config files.
It's close to hopeless. Thus, your proposal a message or three back
to add another BF client config setting to control this sounds like
the worst of all possible worlds. If we needed a change in the
setting, getting the farm to converge to that would take months if not
years. The idea that we could transiently enable checks between beta1
and branch fork on the basis of that approach is downright risible.
On the other hand, if the decisions are driven purely by what is in
our git tree, a change is the work of moments.

regards, tom lane