Re: Which installation parts are backward compatible? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Which installation parts are backward compatible?
Date
Msg-id 11850.1234459207@sss.pgh.pa.us
Whole thread Raw
In response to Which installation parts are backward compatible?  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Which installation parts are backward compatible?
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_migrator and handling dropped columns
Next
From: Tom Lane
Date:
Subject: Re: DISCARD ALL failing to acquire locks on pg_listen