Re: New version numbering practices

On 8/1/16 11:49 AM, Tom Lane wrote:
> Somebody needs to come up with a patch implementing this changeover.

Here is such a patch.  It does not yet implement:

> (External code will need some cue as
> to how to format displays from PG_VERSION_NUM, so we should have a hard
> and fast rule that major >= 10 means new style.)

e.g., in psql, but that's a UI issue that can be sorted out.

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

Some possibilities to make this slightly better:

- Report server_version_num to clients, and use that.

- If libpq can't parse the version number, it should set it to its own
version number instead of 0.  Alternatively,

- If psql sees a server version number of 0, it should assume its own
version number.

- Similarly for pg_dump, although old pg_dump with new server is not
really supported anyway.


Apart from some UI issues, the attached patch passes check-world.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services