Re: New version numbering practices

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New version numbering practices
Date: 2016-08-03 18:15:18
Message-ID: 2185.1470248118@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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".

Ugh.

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

Yeah. I doubt there is much reason to assume that people would be
using, say, a 9.5.5 psql and a 9.5.3 libpq or vice versa. Whatever
the current client behavior is is what people will see.

Having said that, this sort of problem is one reason we wanted to give
ourselves a full year to implement the new scheme. If we put some
appropriate fix into the back branches *now*, there would be a fair
amount of daylight for that to spread into the field before any users
would be seeing v10 servers in practice.

So it seems like fixing libpq's parsing of server_version_num is
something we definitely want to fix ASAP in all back branches.
Is there anything else that's particularly bad?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Hernández Tortosa 2016-08-03 18:15:44 Re: Implementing full UTF-8 support (aka supporting 0x00)
Previous Message Álvaro Hernández Tortosa 2016-08-03 18:14:04 Re: Implementing full UTF-8 support (aka supporting 0x00)