Re: proposal: separate databases for contrib module testing

On 12/02/2012 10:05 AM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> I'd like to change the way we set the CONTRIB_TESTDB name for contrib
>> modules. so that each module doesn't wipe out the previous module's test
>> db.
> Personally I always thought that was a feature not a bug. If we give
> each one its own DB, there will be a couple of dozen databases
> cluttering the installation at the end of "make installcheck", and no
> convenient way to get rid of them. Moreover, what I think you've got
> in mind doesn't work in the "make check" case anyway --- you'd have
> little alternative but to test upgrading each one separately.
>
>

The last point at least doesn't seem relevant. The test script we
currently use for pg_upgrade uses "make installcheck" and the new
cross-version upgrade testing I'm working on relies on having the items
to be upgraded established via "make installcheck".

How about if we have a make target to clean these databases out,
"installcheck-clean", maybe? Alternatively, or in addition, how about if
we have a separate make target to do things the way I'm suggesting,
assuming I can make that work?

Testing upgrading each contrib module separately is really very sub-optimal.

cheers

andrew