Re: Testing with concurrent sessions

On Wed, Jan 6, 2010 at 9:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> It just seems crazy to me to try to test anything without proper
>> language bindings.  Opening a psql session and parsing the results
>> seems extraordinarily painful.  I wonder if it would make sense write
>> a small wrapper program that uses libpq and dumps out the results in a
>> format that is easy for Perl to parse.
>
>> Another idea would be to make a set of Perl libpq bindings that is
>> simpler than DBD::Pg and don't go through DBI.  If we put those in the
>> main source tree (perhaps as a contrib module) they would be available
>> wherever we need them.
>
> We have not yet fully accepted the notion that you must have Perl to
> build (and, in fact, I am right now trying to verify that you don't).
> I don't think that requiring Perl to test is going to fly.

I suppose that depends on the context. I'm not exactly sure what
Kevin's goal is here. For basic regression tests, yeah, we'd probably
like to keep that Perl-free. For more complex testing, I think using
Perl makes sense. Or to put the shoe on the other foot, if we DON'T
allow the use of Perl for more complex testing, then we're probably
not going to have any more complex tests. If we use a hypothetical
concurrent psql implementation to run the tests, how will we analyze
the results? It's no secret that the current regression tests are
fairly limited, in part because the only thing we can do with them is
diff the output against one or two "known good" results.

...Robert