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
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 |