> c) Upgrading between major versions of PostgreSQL requires the DB admin to > bump the database using the old version, moving the database away and to > reload the dump into a new database cluster using the new version of > PostgreSQL. Having to take down the old server and purging the old version > of PostgreSQL before being able to try out the new one is more than > cumbersome. Therefore a slotted postgresql-server is needed to make the > upgrade easier.
As I read upstream's documentation¹, this is incorrect:
# It is recommended that you use the pg_dump and pg_dumpall programs from the
# newer version of PostgreSQL, to take advantage of any enhancements that may
# have been made in these programs. Current releases of the dump programs can
# read data from any server version back to 7.0.
This has also been pointed out in a bug report, duped by some overzealous bug
wrangler a few months ago.
> What do the new ebuilds offer:
> a) A split into dev-db/postgresql-{base,server,docs}. Now, I know that
> splitting up packages isn't the Gentoo way. I know we could have done it
> using USE flags but this approach gives more flexibility due to the current
> way how binary packages are being generated and distributed.
I wouldn't say so. Needlessly growing the forest of odd named, badly
documented and sometimes needlessly added use flags is something I'm not fond
of, looking at the development of Gentoo.
Thanks to everyone taking care of our PostgreSQL packages.
Carsten
[1] http://www.postgresql.org/docs/8.2/interactive/migration.html
signature.asc
Description: This is a digitally signed message part.
