Re: PATCH: Batch/pipelining support for libpq - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: PATCH: Batch/pipelining support for libpq
Date
Msg-id CAB7nPqTuEb5XFPgk17054FRu_k+AXPWHKBAo7KAHtVSQX0G7Vw@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: Batch/pipelining support for libpq  (Andres Freund <andres@anarazel.de>)
Responses Re: PATCH: Batch/pipelining support for libpq  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Tue, Apr 4, 2017 at 8:26 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2017-04-04 09:24:23 +1000, Vaishnavi Prabakaran wrote:
>> Just quickly, Is it not ok to consider only the code patch for this CF
>> without test patch?
>
> I'd say no, it's not acceptable.  This is too much new code for it not
> to be tested.

Doesn't it depend actually? I would think that the final patch may not
include all the tests implemented if:
- The thread on which a patch has been developed had a set of tests
done and posted with it.
- Including them does not make sense if we have a way to run those
tests more efficiently. Sometimes a bunch of benchmarks or tests are
run on a patch bu for the final result keeping them around does not
make much sense.

In the case of this patch, it seems to me that we would have a far
better portable set of tests if we had a dedicated set of subcommands
available at psql level, particularly for Windows/MSVC. If that's a
requirement for this patch so let it be. I am not saying that tests
are not necessary. They are of course, but in this case having a bit
more infrastructure would be more be more helpful for users and the
tests themselves.

Note that I won't complain either if this set of C tests are included
at the end.
-- 
Michael



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: make check-world output
Next
From: Thomas Munro
Date:
Subject: Re: delta relations in AFTER triggers