Re: Patch to fix FK-related selectivity estimates with constants

On 2020-Oct-27, Tom Lane wrote:

> I had two concerns about possible extension breakage from a back-patch:
> 
> * 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.
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.  In this case, at least in core code,
we only pass pointers to the struct around, not the struct itself, so
not a problem; and we only use the struct in lists, not in arrays, so
that's not a problem either.

What other aspects should we consider?


Another angle is usage of the struct by third-party code.  I used
codesearch.debian.net and, apart from Postgres itself, it only found the
string in hypopg (but in typedefs.list, so not relevant) and pgpool2
(which appears to carry its own copy of nodes.h).  Inconsequential.

Searching the web, I did find this:
https://docs.rs/rpgffi/0.3.3/rpgffi/struct.ForeignKeyOptInfo.html but it
appears that this project (an incomplete attempt at a framework to
create Postgres extensions in Rust) mechanically extracts every struct,
but no further use of the struct is done.  I was unable to find anything
actually *using* rpgffi.

It is possible that some proprietary code is using the struct in a way
that would put it in danger, though.