On September 18, 2017 3:50:17 AM PDT, Michael Paquier <michael.paquier@gmail.com> wrote:
>On Mon, Sep 18, 2017 at 6:53 PM, Andres Freund <andres@anarazel.de>
>wrote:
>> On 2017-09-13 23:39:21 -0400, Tom Lane wrote:
>>> The real problem in this area, to my mind, is that we're not testing
>that
>>> code --- either end of it --- in any systematic way. If it's broken
>it
>>> could take us quite a while to notice.
>>
>> Independent of the thrust of my question - why aren't we adding a
>> 'force-v2' option to libpq? A test that basically does something
>like
>> postgres[22923][1]=# \setenv PGFORCEV2 1
>> postgres[22923][1]=# \c
>> You are now connected to database "postgres" as user "andres".
>> postgres[22924][1]=>
>> seems easy enough to add, in fact I tested the above.
>>
>> And the protocol coverage of the v2 protocol seems small enough that
>a
>> single not too large file ought to cover most if it quite easily.
>
>It seems to me that you are looking more for a connection parameter
>here.
I'm not seeing a meaningful distinction here? Env vars and connection parameters are handled using the same framework
inlibpq. And using the env var in the test would be better, because you'd only set one value - hard to do within our
nonTAP tests (i.e. in an existing psql, started by pg regress) otherwise.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
