alternate regression dbs?

Andrew Dunstan <andrew@dunslane.net> writes:

Currently the pg_regress script does "dbname=regression" and then does
everything in terms of $dbname. Would there be any value in providing a
--dbname=foo parameter so that different regression sets could use their
own db? One virtue at least might be that we would not drop the core
regression db all the time - having it around can be useful, I think.

I'd be in favor of using three such DBs, one for core, PLs, and contrib.
(More than that seems like it would clutter the disk a lot.) But I do
use the standard regression DB as a handy testbed for a lot of stuff,
and it has bothered me in the past that the contrib installcheck wipes
it out.

Another point in the same general area: it would probably not be hard to
support "make check" as well as "make installcheck" for the PLs. (The
reason it's hard for contrib is that "make install" doesn't install
contrib ... but it does install the PLs.) Is it worth doing it though?
The easy implementation would require building a temp install tree for
each PL, which seems mighty slow and disk-space-hungry.

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Currently the pg_regress script does "dbname=regression" and then does
everything in terms of $dbname. Would there be any value in providing a
--dbname=foo parameter so that different regression sets could use their
own db? One virtue at least might be that we would not drop the core
regression db all the time - having it around can be useful, I think.

I'd be in favor of using three such DBs, one for core, PLs, and contrib.
(More than that seems like it would clutter the disk a lot.) But I do
use the standard regression DB as a handy testbed for a lot of stuff,
and it has bothered me in the past that the contrib installcheck wipes
it out.

I agree completely, will work on that.

Another point in the same general area: it would probably not be hard to
support "make check" as well as "make installcheck" for the PLs. (The
reason it's hard for contrib is that "make install" doesn't install
contrib ... but it does install the PLs.) Is it worth doing it though?
The easy implementation would require building a temp install tree for
each PL, which seems mighty slow and disk-space-hungry.

yes, way too much work if done as a separate run. The only way it would
make sense to me would be if we integrated them into the core check run
somehow. But I very much doubt it is worth it.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Tom Lane wrote:

The easy implementation would require building a temp install tree for
each PL, which seems mighty slow and disk-space-hungry.

yes, way too much work if done as a separate run. The only way it would
make sense to me would be if we integrated them into the core check run
somehow. But I very much doubt it is worth it.

Yeah. I was seriously thinking of proposing that, until I realized that
putting knowledge of the available optional PLs under src/test/regress
is probably exactly what we don't want to do, given that there are
likely to be more and more of them. We really want that knowledge
localized in src/pl.

Perhaps src/pl/Makefile could be taught to implement "make check" (and
"make installcheck" for that matter) at its own level, and run the tests
for all the configured PLs using only one installation step. But at the
moment it seems more trouble than it's worth.

regards, tom lane

Andrew Dunstan <andrew@dunslane.net> writes:

Try attached ... season to taste. The bulk of it is changes for dblink
which has the dbname hardcoded.

Joe, any objections here?

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Try attached ... season to taste. The bulk of it is changes for dblink
which has the dbname hardcoded.

Joe, any objections here?

Haven't been able to keep up with the lists at all for the past few
days, but I'll take a look later today.

Joe

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Try attached ... season to taste. The bulk of it is changes for dblink
which has the dbname hardcoded.

Joe, any objections here?

Hmm, I can't find the message with the attachment, in my inbox or in the
list archives. Can anyone point me to it?

Joe

Joe Conway wrote:

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Try attached ... season to taste. The bulk of it is changes for
dblink which has the dbname hardcoded.

Joe, any objections here?

Hmm, I can't find the message with the attachment, in my inbox or in
the list archives. Can anyone point me to it?

my fault - I sent the original to the wrong list - meanwhile, Tom, who
was copied on the original, replied to that :-)

Anyway, see
http://archives.postgresql.org/pgsql-patches/2005-05/msg00179.php

cheers

andrew

Andrew Dunstan wrote:

Anyway, see
http://archives.postgresql.org/pgsql-patches/2005-05/msg00179.php

Sorry for the delay -- I'm on the final stretch of a major project at work.

No objections from me.

Joe

Andrew Dunstan <andrew@dunslane.net> writes:

Try attached ... season to taste. The bulk of it is changes for dblink
which has the dbname hardcoded.
There is probably more to be done with the regression stuff, but this
and the earlier change give us the low hanging fruit at least, I think.

Applied with light editorialization on the makefile variables ...

regards, tom lane