Re: New version numbering practices

On 4 August 2016 at 02:15, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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?
>
>
Well, this seems like a good time to make server_version_num GUC_REPORT as
well...

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services