Andres Freund <and...@anarazel.de> writes:
> On 2024-06-03 14:43:17 -0400, David E. Wheeler wrote:
>> * 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.
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. Also, for either the padding-space
or add-at-the-end approaches, we're probably in trouble if some
extension is creating its own instances of such structs, because
it will not know how to fill the new field properly. We try not to
change structs that we think extensions are likely to create ...
but that's a guess not a guarantee.
> It'd be interesting to see a few examples of actual minor-version-upgrade
> extension breakages, so we can judge what caused them.
Yes, that could be a fruitful discussion.
> 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.
For node structs, padding will generally be zero because we memset
them to zeroes. So to the extent that zero is an okay value for
such a new field, that can help --- but if zero were always okay
then we'd likely not need a new field in the first place.
regards, tom lane
