Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
| От | Nathan Bossart |
|---|---|
| Тема | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() |
| Дата | |
| Msg-id | aPKacE_vakRY17FV@nathan обсуждение исходный текст |
| Ответ на | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | 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 по дате отправления: