On Fri, Nov 8, 2013 at 2:23 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > [ still catching up on old email ] > > I wrote: >> Andrew Dunstan <and...@dunslane.net> writes: >>> On 09/11/2013 02:30 PM, Robert Haas wrote: >>>> On Tue, Sep 10, 2013 at 9:53 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>>>> Note that I was proposing removing libpq's support for V2 connections. >>>>> Not the backend's. > >>>> I vote against this. If we remove V2 support from libpq, then we'll >>>> have no easy way to test that the backend's support still works. > >>> How is it tested now, and who is doing the testing? > >> Exactly. The current support in libpq is nigh useless for testing >> purposes, because there's no way to activate that code path on command. >> It only runs if libpq (thinks it) is connecting to a pre-7.4 backend. > > Actually ... there's another way we might deal with this. Suppose we > invent a libpq connection option to specify whether to use v2 or v3 > protocol, defaulting to the latter, and then just remove the protocol- > fallback-during-connection code path. If there is anyone out there using > a modern libpq to talk to a pre-7.4 server, they can be told to invoke > the connection option. This gets rid of the unexpected-protocol-downgrade > problem in a reliable manner, and it also gives us a way to test V2 code > paths in both libpq and the backend, which Andrew is correct to finger as > something that goes nearly totally untested right now. > > The main objections I can see to this are (1) it wouldn't provide > a back-patchable fix, and (2) it'd be adding more legacy code instead > of removing it. But the other approaches that we've talked about didn't > sound very back-patchable either, so I think only (2) really holds > much water.
This approach sounds promising to me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
