-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
>> Using DBI/DBD::Pg would raise another issue - what version of libpq
>> would it be using? Not the one in the build being tested, that's for
>> sure.
>
> Er...why not? That's what psql uses.
> Because you'd have to build DBD::Pg against the new libpq, as you do
> psql. That means you need DBD::Pg sources and the build environment for
> Perl (headers etc) not just a working Perl runtime. Big difference.
Yes, but that is what I was envisioning. As you point out, that's the
only sane way to make sure we have a good version of DBD::Pg with
which to test. As a side effect, it put libpq through some extra
paces as well. :)
> Is bundling a Perl module in the source tree and building it as part of
> the Pg build a reasonable choice? Personally, I don't think so.
*shrug* It's different, but it's the best solution to the problem at
hand. It wouldn't be built as part of Pg, only as part of the tests.
> Additionally, a dedicated testing tool like some folks have been talking
> about would be really handy for users who want to test their schema.
> I've had to write my own (in Java, or I'd be offering it) for this
> purpose, as psql is completely unsuitable for concurrent-run testing and
> I needed to show that my locking was safe and deadlock-free in some of
> the more complex stored procs I have.
Sure, but it's the difference between waiting for someone to write something
(and then dealing with the invevitable bugs, tweaks, and enhancements), or
using a solid, known quantity (DBI + Test::More).
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 201001102316
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAktKplIACgkQvJuQZxSWSsj7TQCeMOXWS+uLIZE9QbeBWPxYv/rg
HhEAn0QZUzE2/8uyg5Oi+K8qL/oTeDSO
=R8Az
-----END PGP SIGNATURE-----