Re: tap tests driving the database via psql - Mailing list pgsql-hackers

From Andres Freund
Subject Re: tap tests driving the database via psql
Date
Msg-id 20190731022053.zluclf3hrdvfw7za@alap3.anarazel.de
Whole thread Raw
In response to Re: tap tests driving the database via psql  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: tap tests driving the database via psql  (Michael Paquier <michael@paquier.xyz>)
Re: tap tests driving the database via psql  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
Hi,

On 2019-07-31 09:32:10 +0800, Craig Ringer wrote:
> OK. So rather than building our own $everything from scratch, lets look at
> solving that.

IDK, a minimal driver that just does what we need it to do is a few
hundred lines, not more. And there's plenty of stuff that we simply
won't be able to test with any driver that's not purposefully written
for testing. There's e.g. basically no way with any of the drivers to
test intentionally bogus sequences of protocol messages, yet that's
something we really ought to test.

I've written custom hacks^Wprograms to tests things like that a few
times. That really shouldn't be necessary.


> Perl modules support local installations. Would it be reasonable to require
> DBI to be present, then rebuild DBD::Pg against our libpq during our own
> test infra compilation, and run it with a suitable LD_LIBRARY_PATH or using
> rpath? That'd actually get us a side-benefit of some test coverage of
> DBD::Pg and libpq.

You're intending to download DBD::Pg? Or how would you get around the
licensing issues? Downloading it will have some issues too: For one at least I
often want to be able to run tests when offline; there's security
concerns too.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Initdb failure
Next
From: Amit Langote
Date:
Subject: Re: Runtime pruning problem