Re: Pains in upgrading to 8.3 - Mailing list pgsql-general

From Dave Page
Subject Re: Pains in upgrading to 8.3
Date
Msg-id 937d27e10802190226p12ffdff9pd010b0805a3df77b@mail.gmail.com
Whole thread Raw
In response to Re: Pains in upgrading to 8.3  (Magnus Hagander <magnus@hagander.net>)
List pgsql-general
On Feb 19, 2008 8:48 AM, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, Feb 18, 2008 at 06:35:11PM -0300, Alvaro Herrera wrote:
> > Bruce Momjian escribió:
> > > Magnus Hagander wrote:
> >
> > > > For the case of upgrading, it wouldn't work. But there are certainly
> > > > other cases where it would help. Say from your central pgadmin console
> > > > administering 10 servers from 3 different major release trees :-(
> >
> > What's wrong with providing statically-linked pg_dump-8.2, pg_dump-8.3
> > and so on, and asking the user which one to use (depending on the target
> > server version)?
>
> Other than the much-increased work in building things, probabliy nothing.
> (The package would be noticably larger as well, of course, but that
> shuouldn't be a big problem today).

I suspect that building static versions of the utilities and retaining
the OpenSSL & Kerberos support would be nigh-on impossible (I've never
even managed to build my own dynamic version of Kerberos (which seems
to rely heavily on the build environment used within MIT).

In pgAdmin, bundling such utilities would be a big no-no. Imagine the
docs - pgAdmin supports SSL encryption and Kerberos authentication,
but if you wish to back or restore your databases you'll need to turn
off those requirements in the server.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Oracle-compatible database company

pgsql-general by date:

Previous
From: Gordon
Date:
Subject: Re: Auto incrementing primary keys
Next
From: Martijn van Oosterhout
Date:
Subject: Re: out-of-line (TOAST) storage ineffective when loading from dump?