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

From David E. Wheeler
Subject Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Date
Msg-id 21ABA09A-3E03-4DDF-BE9D-A916EFD8ABE0@justatheory.com
Whole thread Raw
In response to Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
List pgsql-hackers
On Oct 30, 2025, at 09:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Trouble is, you then need an arbitrary client-made choice about which
> commit to run the ABI check against.

It’s currently coded to use the most recent tag or, if there is none in the branch, the branch root.

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

Fair. Just means that if no one adds a history file to a branch that branch will never be tested and there’s no
automatedway to realize it. 

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

Yeah, it just went with the most recent tag to keep it simple, no other metadata.

D


Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: pg_plan_advice
Next
From: Chao Li
Date:
Subject: Re: Mark ItemPointer arguments as const thoughoutly