On Wed, 3 Dec 2008, Bruce Momjian wrote:
As the author of the original shell script, which was in
/contrib/pg_upgrade, I think the code has grown to the point where it
should be reimplemented in something like Perl.
Ah, there's the common ancestor I couldn't find. Sheesh, you learn Perl
last month, and already you're a zealot. That was fast.
As I see it the priorities for this part are:
1) Finish the shell-based pg_upgrade. The latest one we just got from
Zdenek looks almost there, just have to sort out the dropped column bits.
Start testing that in parallel with the below to figure out if there's
anything that was missed.
2) Re-evaluate what's in there vs. what's already implemented in the
C-based pg_migrator to determine the effort needed to upgrade that to
fully functional.
3) Figure out who is available to do the expected work on schedule.
4) Determine what language they're going to do it in and whether the task
is:
a) Re-implementing the script in a more portable and powerful scripting
language like Perl or Python
b) Adding the additional features needed to complete pg_migrator
c) Writing an implementation into core via some bootstrap process
You suggested (a), I was the latest in a series of people to suggest (b),
and Zdenek suggested (c). They all have different trade-offs in terms of
development time and expected quality of the resulting tool. At this
point we'll be lucky to get anything done, and I think we may have to
settle for whichever of the above options seems most likely to finish
based on the skills of the person(s) doing the job.
I think (c) may be out just because there will be increasing pressure for
a final code freeze on anything in core, so that beta testing can begin on
Jan 1. Whereas something that's going to end up in contrib like either
the final pg_upgrade or an improved pg_migrator might get cut a bit more
slack for starting beta less polished than the core code. (Insert retort
from Tom about how that's not the way it's done here)
Additionally, it may be the case that putting the appropriate hooks in to
support 8.4->8.5 upgrades that have been suggested (dedicated free space
management, catalog support, etc.) is the only thing that ships on time,
and that the 8.4 announcement just mentions "a community tool for in-place
upgrades from 8.3->8.4 is in currently in beta and can be downloaded from
pgforge". That retreat position goes away if you've commited to putting
the whole thing in core.
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
