On Mon, Jun 3, 2024 at 3:38 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Thus I am not really on board with this statement as-is. > > Me either. There are degrees of ABI compatibility, and we'll choose > the least invasive way, but it's seldom the case that no conceivable > extension will be broken. For example, if we can't squeeze a new > field into padding space, we'll typically put it at the end of the > struct in existing branches. That's okay unless some extension has > a dependency on sizeof(the struct), for instance because it's > allocating such structs itself.
Right. While there certainly are code bases (mostly C libraries without a huge surface area) where taking the hardest possible line on ABI breakage makes sense, and where ABI breakage can be detected by a mechanical process, that isn't us. In fact I'd say that Postgres is just about the further possible thing from that. I'm a little surprised that we don't seem to have all that many problems with ABI breakage, though. Although we theoretically have a huge number of APIs that extension authors might choose to use, that isn't really true in practical terms. The universe of theoretically possible problems is vastly larger than the areas where we see problems in practice. You have to be pragmatic about it. -- Peter Geoghegan