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

From Nathan Bossart
Subject Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Date
Msg-id aPKacE_vakRY17FV@nathan
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>)
List pgsql-hackers
On Fri, Oct 17, 2025 at 03:27:10PM -0400, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> I've attached a first try.  You'll notice that I have borrowed heavily from
>> .git-blame-ignore-revs.  Some other things that might be worthwhile:
> 
> There would need to be an initial entry at the time the file is
> created, which would presumably point to some commit shortly before
> the .0 version stamp is applied (or maybe we'd choose to do it around
> rc1).  The mockup should include that.

Sure, makes sense.

> I'd be slightly inclined to have just one non-comment line, which
> is the active reference hash value, and all the rest be comments.
> The way you have it here requires the reading code to be smart
> about end-of-line comments, which is code complexity we don't need
> and doesn't seem amazingly legible either.  OTOH, the precedent of
> .git-blame-ignore-revs may be worth following regardless of our
> personal druthers.

That crossed my mind, too.  I'm personally not too concerned about small
deviations from .git-blame-ignore-revs, especially if it improves
machine/human readability.

-- 
nathan



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
Next
From: Nathan Bossart
Date:
Subject: Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()