Re: Testing of MVCC

Tom Lane wrote:

>Sure, it wouldn't take much to create a minimal C+libpq program that
>would do the basics. But the history of testing tools teaches that
>you soon find yourself wanting a whole lot more functionality, like
>conditional tests, looping, etc, in the test-driver mechanism.
>That's the wheel that I don't want to re-invent. And it's a big part
>of the reason why stuff like Expect and the Perl Test modules have
>become so popular: you have a full scripting language right there at
>your command.
>
>Maybe the right answer is just to hack up Pg.pm or DBD::Pg to provide
>the needed asynchronous-command-submission facility, and go forward
>from there using the Perl Test framework.
>
>
>
>

How will we make sure it's consistent? People have widely varying
versions of DBD::Pg and DBI installed, not to mention the bewildering
array of Test::Foo modules out there (just try installing Template
Toolkit on a less than very modern perl and see yourself get into module
hell). The only way I can see of working on this path would be to keep
and make our own copies of the needed modules, and point PERL5LIB at
that collection. But that would constitute a large extra buildtime burden.

A better solution might be to hack something out of the pure perl DBD
driver and use that. It's known to have some problems, but maybe this
would be a good impetus to iron those out, and this would reduce us to
carrying a single non-compiled perl module (plus whatever test framework
we need).

cheers

andrew