On 4 August 2016 at 02:15, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Wed, Aug 3, 2016 at 12:12 PM, Peter Eisentraut > > <peter.eisentr...@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". > > 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
