From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Toward pg_upgrade |
Date: | 2005-07-14 04:41:13 |
Message-ID: | 42D5ECE9.1050002@samurai.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | clipper tokyo | 2005-07-14 06:31:06 | Question about convert the binary WAL file |
Previous Message | David Fetter | 2005-07-14 03:58:24 | test |