Re: 7.1 Release Date

   We NEED this 'pg_upgrade'-on-steroids program that simply Does The Right
   Thing.

   I think it's high time that the dump/initdb/restore cycle needs to be
   retired as a normal upgrading step.

YOU (i.e., people relying on the RH stuff to do everything at once)
may need such a thing, but it seems like you are overstating the case
just a bit.  If this project gets adopted by core developers, it would
seem to conflict drastically with the goal of developing the core
functionality.  Thus, it's not quite "high time" for this.

There is nothing inherently different (other than implementation
details) about the basic procedure for upgrading the database as
compared to upgrading user data of any sort.  In each case, you need
to go through the steps of 1) dump data to a secure place, 2) destroy
the old stuff, 3) add new stuff, and 4) restore the old data.  In the
case of "normal" user data (home directories and such) the
dump/restore sequence can be performed using exactly those commands or
tar or dd or whatever.  In the case of the database we have the
pg_dump/psql commands.  In either case, the person doing the upgrade
must have enough of a clue to have made an appropriate dump in the
first place before trashing their system.  If the person lacks such a
clue, the solution is education (e.g., make the analogy explicit, show
the tools required, make pg_dump more robust, ...) not redirecting the
precious resources of core developers to duplicate the database system
in a standalone program for upgrades.

Cheers,
Brook