From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New version numbering practices |
Date: | 2016-08-03 18:03:51 |
Message-ID: | CA+TgmobYm+-hLaHyYwNrv31-PAahrzcW_gOq5B-ptw8vJ-Afng@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 3, 2016 at 12:12 PM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-08-03 18:09:24 | Re: PostmasterContext survives into parallel workers!? |
Previous Message | Joshua Bay | 2016-08-03 18:02:06 | Re: Way to access LSN (for each transaction) by directly talking to postgres? |