Re: alternate regression dbs? - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: alternate regression dbs?
Date
Msg-id 42867E4A.6020200@dunslane.net
Whole thread Raw
In response to Re: alternate regression dbs?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: alternate regression dbs?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: alternate regression dbs?
Next
From: Tom Lane
Date:
Subject: Re: alternate regression dbs?