Robert Haas <robertmh...@gmail.com> writes: > On Fri, Oct 7, 2016 at 11:34 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> 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. I experimented with this and found out that a majority of the regression tests fall over, because the error messages come out formatted differently when using V2. You don't get separate DETAIL or HINT fields, nor cursor positions, etc. So there's boatloads of silly diffs like this: *************** *** 69,75 **** INSERT INTO testschema.atable VALUES(3); -- ok INSERT INTO testschema.atable VALUES(1); -- fail (checks index) ERROR: duplicate key value violates unique constraint "anindex" - DETAIL: Key (column1)=(1) already exists. SELECT COUNT(*) FROM testschema.atable; -- checks heap count ------- --- 69,74 ---- Some of the tests have harder-to-ignore failures because protocol V2 had no way to recover from a failure during COPY IN, short of aborting the connection: --- 34,42 ---- -- missing data: should fail COPY x from stdin; ERROR: invalid input syntax for integer: "" ! FATAL: terminating connection because protocol synchronization was lost COPY x from stdin; ! server closed the connection unexpectedly ! This probably means the server terminated abnormally ! before or while processing the request. ! connection to server was lost At this point I'm feeling pretty discouraged about testability of V2. I can't see us maintaining a variant regression test suite that would accommodate these issues. So the easy idea of "build with some extra #define and then run the usual regression tests" is out. Now, we hardly need the entire regression suite to provide adequate coverage of V2 protocol. You could imagine a small dedicated test that just checks basic commands, errors, notices, COPY. The problem is that we'd need infrastructure in either the backend or libpq to dynamically force use of V2 for that test, and that's work that I for one don't really care to put in. Not sure where to go from here, but the idea of dropping V2 support is seeming attractive again. Or we could just continue the policy of benign neglect. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers