Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats()
| От | Peter Eisentraut | 
|---|---|
| Тема | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() | 
| Дата | |
| Msg-id | 61bd5c85-aaee-4a73-aba6-5b725eacdf27@eisentraut.org обсуждение исходный текст  | 
		
| Ответ на | 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 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 по дате отправления: