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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Mankirat Singh <mankiratsingh1315(at)gmail(dot)com>, pg(at)bowt(dot)ie, andrew(at)dunslane(dot)net, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Date: 2025-10-31 15:17:11
Message-ID: 3537858.1761923831@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> On Fri, Oct 31, 2025 at 12:02:10PM +0100, Peter Eisentraut wrote:
>> 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?

> I think either way would ultimately be fine. I might argue that keeping
> the full history in a file with detailed explanations is more accessible
> than requiring folks to run
> git log .abi-compliance-history
> (Plus, if someone doesn't bother to put details in the commit message, you
> then have to sleuth further to figure out what changed.)

Yeah, that last. I would expect the annotation text in
.abi-compliance-history to be specific about the nature of the ABI
break, whereas the log message for the commit that changed things
might not bother with such details.

As we move along with this effort, we might ultimately decide that
this scheme is overdoing the amount of detail recorded. But to
start with, I'd rather err on the side of recording more info
not less.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuro Yamada 2025-10-31 15:19:07 [PATCH] psql: add \dcs to list all constraints
Previous Message Karina Litskevich 2025-10-31 14:45:07 Re: doc: Improve description of io_combine_limit and io_max_combine_limit GUCs