Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2020-Oct-27, Tom Lane wrote:
>> * Changing the set of fields in ForeignKeyOptInfo is an ABI break.
>> We could minimize the risk by adding the new fields at the end in
>> the back branches, but it still wouldn't be zero-risk.
> It'd be useful to be able to qualify this sort of risk more objectively.
Agreed.
> I think if a struct is used as a function argument somewhere or arrays
> of the struct are formed, then it's certain that changing that struct's
> size is going to cause problems.
I grasp the point about arrays, but not sure how it's a problem for
function arguments per se? Or were you thinking of functions that
take a struct as pass-by-value not pass-by-reference?
The way I've generally thought about this is that new fields added to the
end of a Node struct are only likely to be a hazard if extension code
creates new instances of that Node type. If it does, it's certainly
problematic, first because makeNode() will allocate the wrong amount of
storage (ABI issue) and second because the extension won't know it needs
to fill the new fields (API issue). However if we don't expect that that
will happen, then it's probably going to be OK. Code that just inspects
Nodes made by the core code won't be broken, as long as we don't change
the semantics of the existing fields. We don't ever pass Node structs by
value, and we don't make arrays of them either, so the actual size of the
struct isn't much of an ABI issue.
As you say, we can also search to see if there seem to be any extensions
using the struct in question. I don't have a huge amount of faith in
that, because I think there are lots of proprietary/custom extensions
that aren't visible on the net. But on the other hand, the users
of such extensions probably wouldn't have much trouble rebuilding them
for a new version, if they did get bit. It's the widely distributed
extensions that might have users not capable of dealing with that.
regards, tom lane