> > 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. > > That’s what I was thinking, so “compatibility assured only if you don’t use > padding yourself” would be super helpful.
I was under the impression that the (a?) concern was related to compiling the newer version and using that against an older version, so if you always compiled the extension against the latest point release, it wouldn't necessarily be backwards-compatible with older installations. (While probably allocated padding is zero'd out in the old version, I'd not guarantee that that's the case.) > >> 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. > > Sure, probably not a problem, but if that’s the sole qualifier for making > binary changes, I think it’s worth saying, as opposed to “we don’t make any”. > Something like “Only changes to padding, which you never used anyway, right?” > :-) Wonder if what might be more useful is some sort of distribution list for extensions authors to be notified of specific compatibility changes. Could be powered by parsing commit messages for conventions about backwards-incompatible changes; padding usage could be one, maybe there are others we could code for. (For padding, imagine a tool that is able to look at struct offsets between git revisions and note any offset differences/changes here that extensions authors could be aware of; even diffs of `pahole` output between revisions could be helpful.) ABI guarantees for extensions are hard because all of core *is* potentially the ABI (or at least if you are well-behaved, public functions and structs), so some sort of "these interfaces won't break in minor releases but use other internals and you're on your own" might be useful distinction. (We discussed trying to classify APIs with varying levels of support, but that also comes with its own set of issues/overhead/maintenance for code authors/committers.)
