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

From Peter Eisentraut
Subject Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Date
Msg-id 61bd5c85-aaee-4a73-aba6-5b725eacdf27@eisentraut.org
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 21.10.25 22:13, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> For the rest of the back-branches, I'm considering starting with a baseline
>> of the latest minor version stamps.  While it would be nice to have a
>> comprehensive history of the ABI compatibility for each major version,
>> we've lived this long without it, and I think it's unlikely that we'd act
>> on any breakages that predate the latest release set.  Thoughts?
> 
> Agreed that building a full list of ABI-changing commits in those
> branches is probably not worth the trouble at this point.  (My OCD
> side kind of wants to do it anyway ... but it's hard to argue that
> we'd get real value out of it, or that we'd change anything now
> unless we get complaints.)

What is the reason that this file is supposed to contain the history of 
relevant changes, rather than just the last one?

If you want the history, you could look at the git log of the file 
itself, no?




pgsql-hackers by date:

Previous
From: Vaibhav Dalvi
Date:
Subject: [PATCH] Add pg_get_subscription_ddl() function
Next
From: "Jelte Fennema-Nio"
Date:
Subject: Re: libpq: Bump protocol version to version 3.2 at least until the first/second beta