Re: Which installation parts are backward compatible?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Which installation parts are backward compatible?
Date: 2009-02-12 17:20:07
Message-ID: 11850.1234459207@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I've been examining multi-major-version binary packaging again, and I was
> wondering whether we have a good overview over which pieces of the
> installation are backward compatible (that is, they can be shared between all
> major versions) and which are not. For example, psql 8.4 can now presumably
> be shared between all major versions, so previous schemes to have several
> psqls installed can be simpified.

ISTM that having psql alone be cross-version-compatible will be just
about completely uninteresting to packagers. If we could make *all*
the user-facing executables be cross-version, then we'd be getting
somewhere; it would be possible to install them all in /usr/bin and
just have a version-specific subdirectory under /usr/libexec or
someplace for the rest of the stuff, which users wouldn't need to
have in their PATH anyway.

Looking at your list, it seems the only part of that that might not
be within reach is that pg_dump output from version N typically
doesn't load into server versions < N. pg_dump is complicated enough
without trying to make it handle that too :-(.

The other parts to worry about are libraries (but existing shlib
versioning schemes may be enough for that) and include files.
Not sure what to do with include files.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-02-12 17:21:07 Re: DISCARD ALL failing to acquire locks on pg_listen
Previous Message Tom Lane 2009-02-12 17:01:27 Re: pg_migrator and handling dropped columns