Re: New version numbering practices - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: New version numbering practices
Date
Msg-id CAMsr+YE3vK+j8juJ1cjFh6Yi8EXWnMMB0XqOBVxGeG0PPOAUQA@mail.gmail.com
Whole thread Raw
In response to Re: New version numbering practices  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: New version numbering practices  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 4 August 2016 at 12:45, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Craig Ringer <craig@2ndquadrant.com> writes:
> On 4 August 2016 at 02:15, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So it seems like fixing libpq's parsing of server_version_num is
>> something we definitely want to fix ASAP in all back branches.

> Well, this seems like a good time to make server_version_num GUC_REPORT as
> well...

To what end?  Existing versions of libpq wouldn't know about it, and new
versions of libpq couldn't rely on it to get reported by older servers,
so it'd still be the path of least resistance to examine server_version.

Because it's really silly that we don't, and since we're making a change that will affect clients anyway (the argument against doing it before), lets do it.

Otherwise why bother ever adding anything, since it'll take time for clients to use it? 

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

pgsql-hackers by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: [RFC] Change the default of update_process_title to off
Next
From: Michael Paquier
Date:
Subject: Re: [RFC] Change the default of update_process_title to off