Re: Which installation parts are backward compatible?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Which installation parts are backward compatible?
Дата
Msg-id 11850.1234459207@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Which installation parts are backward compatible?  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Which installation parts are backward compatible?
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_migrator and handling dropped columns
Следующее
От: Tom Lane
Дата:
Сообщение: Re: DISCARD ALL failing to acquire locks on pg_listen