Robert Haas <robertmh...@gmail.com> writes: > On Thu, Aug 4, 2016 at 9:57 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> [ shrug... ] What do you claim is not machine-readable about >> server_version?
> Surely you can't have missed the connection between the issue at hand > and what Craig is talking about. If libpq were using the > machine-readable version rather than PARSING A STRING, switching to a > two-part numbering scheme wouldn't force a compatibility break. Well, yeah, this specific case would not have broken, because we intentionally chose to maintain backwards compatibility of the PG_VERSION_NUM data format. But I think there's nothing much except wishful thinking backing up the idea that starting to send server_version_num now will prevent a bug in future. If we ever do change our version numbering scheme again, it would quite possibly be in a way that breaks PG_VERSION_NUM as well. A fairly obvious potential reason to need to change something there is overflow of the two-digit fields: clients relying on PG_VERSION_NUM would be *more* at risk, not less so, than clients looking at a string. In short: if we'd done it that way all along, it would've been nice. But encouraging people to change horses now isn't really going to make things better. What is far more likely to happen, if we were to do that, is that people will make clients that gratuitously fail on old server versions because they didn't bother to support or test for the case that the server doesn't send server_version_num. You don't really want to encourage multiple ways of identifying which software version you're dealing with. That way madness lies. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers