On Wed, Sep 11, 2013 at 2:35 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> 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. And
>> we've got too many people using V2 to think that it's OK not to have
>> an easy way of testing that. I think the question we ought to be
>> asking is: how can we get widely-used connectors to stop relying on V2
>> in the first place?
>
> How is it tested now, and who is doing the testing?
I don't know that there's any automated testing, but if someone
reports a bug that can only be reproduced using the v2 protocol, the
first thing I'm going to try to do is reproduce that using libpq, just
as I would with any other connector malfunction. From what's being
said here it sounds like I might have to hack libpq a bit to get it to
speak the v2 protocol, but how long is that going to take? Less time
than setting up an environment that can run whatever crazy connector
the client is using and trying to figure out whether the client or the
server is to blame, for sure.
Don't get me wrong, I think that the v2 protocol should go away, but
the real issue is the connectors that are still relying on it as a
primary way of talking to the server, not libpq. We could force all
of those connectors to update or die by removing server support, and
once the server support is gone I don't care about libpq any more. Or
maybe there's some friendlier way to wean those connectors off v2.
But in the meantime I'm skeptical that removing the code from libpq
gets us anywhere.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
