Folks,
I'm sure I'm not the first to bring up this way of doing pg_upgrade,
but perhaps I can help seed a fruitful discussion on the matter.
As background, I'd like to go over our policy of, "The code patch must
be accompanied by any doc patches that it implies." I believe that
this policy is good and wise, as it has helped produce both extremely
high code quality and product usability over the years, and that it
will continue to do the same as time goes on.
So here's my Modest Proposalâ¢.
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.
By "upgrade transformations," I mean:
* Things that change the storage format from the pre-patched
version to what the post-patched version, and
* Things that transform configuration files from the pre-patched
version to the post-patched version.
* The ever-popular Stuff Dave Hasn't Thought Of That People Bark Their
Shins On.
Ideally, these transformations would be both idempotent and
reversible, although I understand that they may, by their nature, be
neither.
Advantages of making this policy change:
* Pg_upgrade actually happens as a matter of routine
* It's testable one change at a time
Disadvantages:
* Increased work on the front-end for new changes
* Higher barriers to entry
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
