David Fetter wrote:
As background, I'd like to go over our policy of, "The code patch must
be accompanied by any doc patches that it implies."
Although it is worth noting this policy is not religiously followed
anyway (e.g. the recent roles patch). I think we basically assume that
the person contributing a code patch is on the hook to write the docs at
some point before the next release, unless they can convince someone
else to do it for them.
Where the rule now reads,
The code patch must be accompanied by any doc patches that it implies.
It should read,
The code patch must be accompanied by any doc patches *and any needed
upgrade transformations* that it implies.
I think this misses the point. The hurdle that needs to be cleared for
pg_upgrade is to write the infrastructure needed to migrate the system
catalogs and data directories from one release to another in a reliable
way. Once that is done, then yes, subsequent system catalog
modifications would need to include the necessary changes to the upgrade
infrastructure to make pg_upgrade continue to work. But until we have
pg_upgrade in the first place, the requirement you state above could be
simplified to "no changes that would require an initdb", which is
obviously a non-starter.
-Neil
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
