On 8/01/2010 1:39 AM, Greg Sabino Mullane wrote:
-----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.
There's no guarantee the user's machine has the same major version of
libpq and thus no guarantee that DBD::Pq can be redirected to use your
custom libpq by LD_LIBRARY_PATH. It might also override the library
search path with rpath linking. Building your own would be pretty much
unavoidable unless you're prepared to either require the user to provide
a matching version of DBD::Pg or have the tests running with whatever
random version happens to be lying around.
Using whatever DBD::Pg version happens to be present on the machine
would be a bit of a nightmare for reproducibility of test results, and
would be really unattractive for use in the standard tests. "make check
fails on my some-random-distro" would become painfully common on the
GENERAL list...
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.
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.
--
Craig Ringer
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
