On Fri, Oct 7, 2016 at 11:34 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Stark <stark@mit.edu> writes:
>> On Fri, Oct 7, 2016 at 3:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> In the same line, maybe we should kill libpq's support for V2 protocol
>>> (which would make the cutoff 7.4). And maybe the server's support too,
>>> though that wouldn't save very much code. The argument for cutting this
>>> isn't so much that we would remove lots of code as that we're removing
>>> code that never gets tested, at least not by us.
>
>> Somehow removing the whole protocol support seems a bit different to
>> me than removing pg_dump logic. For one it's nice to be able to run a
>> modern psql against old servers so you can run a benchmark script.
>
> Yeah, but surely pre-7.4 servers are no longer of much interest for that;
> or if you want historical results you should also use a matching libpq.
>
>> For another there may be binary-only applications or drivers out there
>> that are using V2 for whatever reason.
>
> The problem with letting it just sit there is that we're not, in fact,
> testing it. If we take the above argument seriously then we should
> provide some way to configure libpq to prefer V2 and run regression
> tests in that mode. Otherwise, if/when we break it, we'll never know it
> till we get field reports.
I agree with that. I think it would be fine to keep V2 support if
somebody wants to do the work to let us have adequate test coverage,
but if nobody volunteers I think we might as well rip it out. I don't
particularly enjoy committing things only to be told that they've
broken something I can't test without unreasonable effort.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
