Hi,
On 2024-06-03 14:43:17 -0400, David E. Wheeler wrote:
> At the PGConf Unconference session on improving extension support in core,
> we talked quite a bit about the recent anxiety among extension developers
> about a lack of an ABI compatibility guarantee in Postgres.
Are there notes for the session?
> Yurii Rashkovskii did a little header file spelunking and talked[1] about a
> few changes in minor version releases, including to apparent field order in
> structs.
It'd be nice if the slides for the talk could be uploaded...
> > You must be referring to my commit 714780dc. The new field is stored within alignment padding (though only on back
branches).Has this been tied to a known problem?
>
> At the Unconference, Tom Lane said that this approach is pretty well drilled
> into the heads of every committer, and new ones pick it up through
> experience. The goal, IIUC, is to never introduce binary incompatibilities
> into the C APIs in minor releases. This standard would be good to document,
> to let extension developers know exactly what the guarantees are.
I don't think we can really make this a hard guarantee. Yes, we try hard to
avoid ABI breaks, but there IIRC have been a few cases over the years where
that wasn't practical for some reason. If we have to decide between a bad bug
and causing an ABI issue that's unlikely to affect anybody, we'll probably
choose the ABI issue.
> * The ABI is guaranteed to change only in backward compatible ways in minor
> releases. If for some reason it doesn’t it’s a bug that will need to be
> fixed.
Thus I am not really on board with this statement as-is.
Extensions in general can do lots of stuff, guaranteeing that bug fixes don't
cause any problems is just not feasible.
It'd be interesting to see a few examples of actual minor-version-upgrade
extension breakages, so we can judge what caused them.
> But if I understand correctly, the use of techniques like adding a new field
> in padding does not mean that extensions compiled on later minor releases
> will work on earlier minor releases of the same major version.
I don't think it's common for such new-fields-in-padding to cause problems
when using an earlier minor PG version. For that the extension would need to
actually rely on the presence of the new field, but typically that'd not be
the case when we introduce a new field in a minor version.
> Unless, that is, we can provide a complete list of things not to do (like
> make use of padding) to avoid it. Is that feasible?
You can't really rely on the contents of padding, in general. So I don't think
this is really something that needs to be called out.
Greetings,
Andres Freund
