Re: Toward pg_upgrade - Mailing list pgsql-hackers

From Neil Conway
Subject Re: Toward pg_upgrade
Date
Msg-id 42D5ECE9.1050002@samurai.com
Whole thread Raw
In response to Toward pg_upgrade  (David Fetter <david@fetter.org>)
Responses Re: Toward pg_upgrade  (David Fetter <david@fetter.org>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: test
Next
From: Hannu Krosing
Date:
Subject: Re: [Bizgres-general] A Guide to Constraint Exclusion