I was just looking at the latest pg_upgrade revision. Maybe it works for
particular installations, but before we can think about releasing this, at
least the issues below need to be addressed.
It seems to require that the data directory is under a directory named
"data" and that your current directory is above that. This is not
appropriate for real software. I suggest using standard -D options and/or
the PGDATA environment variable.
The locations of directories like the INFODIR and the OLDDIR should be
configurable. Don't just put them where they happen to fall. (Remember
that possibly a lot of data will end up there.)
The way temp files are allocated looks very insecure. And does this thing
even check under what user it's running?
'test -e' is not portable.
'grep -q' is not portable. (At least it doesn't portably behave as you
might think it does.)
Although 'head' is probably portable, it has never been explored, because
'sed 1q' is better.
If you set an exit trap, then 'exit 1' is not portable. (I'm not kidding,
see pg_regress.)
You can't nest " inside ` inside ".
Pattern matching with 'expr' should be invoked like this: expr x"$OBJ" :
x'pg_', or it might blow up when $OBJ has funny values.
Moving directories with 'mv' is not necessarily a good idea.
Should do a lot more error checking.
psql, pg_ctl, etc. should not just be called from the path. You know the
install directory, so use that.
awk should be called as determined by configure.
Poor quality (spelling, wording) of messages.
The man page is very confusing.
--
Peter Eisentraut peter_e@gmx.net