Re: Potential ABI breakage in upcoming minor releases

Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> writes:
> I would also add something like the following, to protect against
> corruption and deserialization errors of the catalog pg_node_tree
> fields, because right now the generated readfuncs.c code ignores field
> names, assumes ABI field order, and is generally quite sensitive to
> binary changes, which can cause corruption and/or errors during
> readback of those nodes:

> * If you update the contents of Nodes which are stored on disk as
> pg_node_tree, you also have to make sure that the read function for
> that node type is able to read both the old and the new serialized
> format.

No, actually that policy is "You cannot change the contents of
Node structs at all if they could appear in stored views, rules,
default expressions, etc". We don't do catversion bumps in back
branches, which means that catalog contents have to be backwards
as well as forwards compatible across minor releases.

That's not really something that belongs under the heading of
ABI breaks, I think. It's about "the on-disk representation of
catalogs is frozen within a release series", which extends to
more things than Nodes. Still, maybe a parenthetical remark
wouldn't hurt. Perhaps:

(Keep in mind also that Node structs can't be changed at all
if they might appear in stored views, rules, etc.)

regards, tom lane