Thread: alternate regression dbs?
I meant to mention this during previous discussion. 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. cheers andrew
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