From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Is it time to kill support for very old servers? |
Date: | 2017-10-11 01:09:34 |
Message-ID: | CAB7nPqTsoK0_sn3RXiKDayu00sqFV0JgvB6x2sT7pauAZUvywA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 11, 2017 at 9:39 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2017-09-20 01:32:36 -0700, Andres Freund wrote:
>> Coverage of the relevant files is a good bit higher afterwards. Although
>> our libpq coverage is generally pretty damn awful.
>
> Any opinions on this? Obviously this needs some cleanup, but I'd like to
> know whether we've concensus on adding a connection option for this goal
> before investing more time into this.
>
> A nearby thread [1] whacks around some the v2 code, which triggered me
> to look into this. I obviously can just use thiese patches to test those
> patches during development, but it seems better to keep coverage.
FWIW, I think that moving forward with such a possibility is a good
thing, including having a connection parameter. This would pay in the
long term if a new protocol version is added. 0001 should document the
new parameter.
+ if (conn->forced_protocol_version != NULL)
+ {
+ conn->pversion = atoi(conn->forced_protocol_version);
+ }
This should check for strlen > 0 as well.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-10-11 01:14:27 | Re: Is it time to kill support for very old servers? |
Previous Message | Joe Conway | 2017-10-11 01:06:03 | pg_regress help output |