On Tue, 13 Jan 2004, Michal Pasternak wrote:

> Well, in such case it means that the best possible option is to name every
> postgresql package including it's version number (postgresql-server73,
> postgresql-server74, postgresql-server80 -- this won't be a big problem if
> the base metapackage will have enough configureable options) and to make it
> install every single file in a separate directory hierarchy
> (${PREFIX}/pgsql72, ${PREFIX}/pgsql73). Data directory could be located
> inside that hierarchy. Such action would also need to test every
> postgresql-lib or postgresql-client dependent package.

This is, IMHO, the best way to go. I'm sure I'm not unusual in that on
my development machines I usually have both the current and previous
revisions of postgresql running because I have to support both--some
production machines have been upgraded; others have not. I even have had
production machines running both for a while during a migration.

For the data directory, I suggest changing the rc scripts to be named
pgsql73, pgsql74, etc., and having them use the version number in
the data directory as well (data73, data74, etc.), since there is no
possible way that 7.4 could use a 7.3 data directory or vice versa.

As far as automatic dump and reload goes; there are several issues:

    1. You have to find room to do the dump, which may be difficult
    or even impossible for a large database on any particular machine
    configuration.

    2. The dump/restore process might take several hours, which could
    be a pain.

    3. You don't know that the user even wants to copy the data over to
    the new database; for my default development server configuration I
    definitely do *not* want my 7.3 data moved over to 7.4.

    4. You may not be able to restore the dump without editing the dump
    file first. For example, currently pg_dump dumps CHECK constraints
    on tables before it dumps function definitions, so if a CHECK
    constraint uses a function definition, the restore will fail. (This
    is a bug in pg_dump, but that's a separate issue.) There may also be
    incompatibilities between versions that require the database schema
    to be changed in some way.

There is such a wide variety of ways to set up and use PostgreSQL that
the automated dump/restore thing just don't fly for me; it would work
only for some very simple configurations. That said, if someone wants to
write it, feel free, so long as it's optional.

Just for what it's worth, the company I work for (Vanten K.K.) is the
official representative of PostgreSQL Inc. in Japan, and so we've got
a direct line to the PostgreSQL developers should there be issues that
we can help with. Contact me off-list if you want to discuss anything
related to this.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.NetBSD.org
    Don't you know, in this new Dark Age, we're all light.  --XTC