Hi, On Mon, Nov 25, 2024 at 08:56:50PM -0500, Tom Lane wrote: > [ getting back to the document-ABI-breakage-rules-better topic ... ] > > I wrote: > > That text says exactly nothing about what specific code changes to > > make or not make. I'm not sure offhand where (or if) we have this > > documented, but there's an idea that adding fields at the end of > > a struct is safer ABI-wise than putting them in the middle. Which > > is true if you can't squeeze them into padding space. Here, that > > could have been done and probably should have. > > I remembered where that's documented: > > https://wiki.postgresql.org/wiki/Committing_checklist#Maintaining_ABI_compatibility_while_backpatching > > I propose rewriting and expanding that: > > * Don't change the contents of globally-visible structs, specifically > not the offsets of existing fields. If you must add a new field, > the very best way is to put it into existing alignment padding > between fields. (But consider both 32-bit and 64-bit cases when > deciding what is "padding".)
What about providing a decision table to help considering for 32-bit, something like (proposed in [1])? 64-bit hole size | use on 32-bit? -----------------|--------------- <=3 bytes | safe to use 4 bytes | don't use 5-7 bytes | use first (hole_size - 4) bytes only [1]: https://www.postgresql.org/message-id/flat/ZzcR%2BoQmUOIm6RVF%40ip-10-97-1-34.eu-west-3.compute.internal#08182ae6a6719632acf52fe4d90e9778 Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
