On Mon, Jun 3, 2024 at 3:38 PM Tom Lane <tgl@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