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 | aPKFmL8VjOKNVLcw@nathan обсуждение исходный текст  | 
		
| Ответ на | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Ответы | 
                	
            		Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
            		
            		 | 
		
| Список | pgsql-hackers | 
On Fri, Oct 17, 2025 at 01:15:20PM -0400, Tom Lane wrote: > FWIW, I favor the approach of having an in-tree, per-branch file > containing the commit hash of a commit that is the current ABI > reference for that branch. If the file doesn't exist (which it > wouldn't in master, and probably not in recently-forked branches), > skip ABI checking. I think this is superior to the discussed > alternative of depending on git tags, because files are easy to > change or remove, while tags are not. In particular, I think it'd > likely be impossible to make the ABI reference point go backwards > if we use tags. Maybe that's not a case we'd ever need, but I'm > unconvinced of that. I'm new to the topic, but IMHO the per-branch file approach is by far the best approach. Not only is it much more flexible, but we could even use it as a centralized list of ABI breaks for a given branch with justification for each. I can't think of any strong advantages of keeping this stuff in git metadata. git itself uses a file for blame.ignoreRevsFile... -- nathan
В списке pgsql-hackers по дате отправления: