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

From Tom Lane
Subject Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Date
Msg-id 3019008.1761832542@sss.pgh.pa.us
Whole thread Raw
In response to Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()  ("David E. Wheeler" <david@justatheory.com>)
Responses Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
List pgsql-hackers
"David E. Wheeler" <david@justatheory.com> writes:
> Might I suggest, however, that it also run for branches matching /_STABLE$/ even if there is no .abi-hstory-file? The
wholepoint of this exercise was to increase the confidence in ABI stability in stable branches. Running it in such
brancheswould help remind maintainers to add the file. 

Trouble is, you then need an arbitrary client-made choice about which
commit to run the ABI check against.  If that code does something we
realize we don't want, we're back up against the problem of moving the
buildfarm configuration to fix it.  I'd rather the decision be opt-in.

(Also, the only rules I heard proposed for such client-driven choices
involved git tags.  I already explained why I don't want that: git
tags are hard to modify and subject to too many other constraints.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Mats Kindahl
Date:
Subject: Re: Coccinelle for PostgreSQL development [1/N]: coccicheck.py
Next
From: Peter Eisentraut
Date:
Subject: Re: Consistently use the XLogRecPtrIsInvalid() macro