Re: New version numbering practices

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: New version numbering practices
Дата
Msg-id CA+TgmobYm+-hLaHyYwNrv31-PAahrzcW_gOq5B-ptw8vJ-Afng@mail.gmail.com
обсуждение исходный текст
Ответ на Re: New version numbering practices  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: New version numbering practices  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Aug 3, 2016 at 12:12 PM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> One hiccup I found is that server_version_num is not sent to clients.
> Instead, libpq assembles the numeric version number itself from the
> string version, and it will fail if it sees only one number (e.g.,
> 10devel).  It will then set the version number to 0 for "unknown".
> Client code such as psql and pg_dump is coded so that it will then fall
> back to code for the oldest server version it happens to support (less
> than 8.1 at times).  So in other words, old psql plus new server up
> until production release will have many \d commands failing.  Once the
> release becomes 10.0, it will work again.  (It will still think in terms
> of three-component versions, but it won't make a difference in practice.)

This pretty much sucks.  I suppose we could at least alleviate the
problem by back-patching some intelligence about the new scheme into
back-branches, but of course that will only help people if they
install newer minor releases.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Joshua Bay
Дата:
Сообщение: Re: Way to access LSN (for each transaction) by directly talking to postgres?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PostmasterContext survives into parallel workers!?