> However, on that note, just "installing the darn module" may not be possible
> without skipping the tests.
>
> There are additional pieces of information needed:
> $ENV{DBDPG_TEST_DB}
> $ENV{DBDPG_TEST_HOST}
> $ENV{DBDPG_TEST_USER}
> $ENV{DBDPG_TEST_PASS}
> (prevents mucking up a real database)
>
> Other DBD::* modules require DBI_DSN, DBI_USER, DBI_PASS to run the
> tests. Without the correct setup installing from CPAN will fail.
>
You forgot $ENV{DBDPG_MAINTAINER}. Wich if not not set will cause DBD::Pg
to skip all of its tests other than t/01basic. This behaviour is new with
DBD::Pg 1.1x, the older versions did attempt to run the tests without
intervention.
This having to set the envionment variable is driving me nuts, and I think
is causing people to skip running the tests, as evedenced by Peter, just
now, finding 3 of the tests were broken because the checks were backwards.
The module could make an attemnt to connect to the database. If the
connect fail, skip the tests until the envionment variables are set. And
speaking of the envionment variables, why are DBDPG_TEST env's even needed
when we already have DBI_DSN &c. and postgres has PG_USER, PG_HOST.
As for mucking up a database, you could look to see if a database, say
"DBD::Pg 1.13 -- Testing database" exist. If it exist, thow an error (or
look for "DBD..base 1"), otherwise create the db and use it for testing.
Also while we are on testing, it would be nice to have DBD::Pg connect to
a UDS if a host is not speciified. If I am not going to be running
postgres with inet sockes why should I be forced to test Pg over them?
-r
