Re: proposal: separate databases for contrib module testing
От | Andrew Dunstan |
---|---|
Тема | Re: proposal: separate databases for contrib module testing |
Дата | |
Msg-id | 50BB76E7.4090803@dunslane.net обсуждение исходный текст |
Ответ на | Re: proposal: separate databases for contrib module testing (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: proposal: separate databases for contrib module testing
|
Список | pgsql-hackers |
On 12/02/2012 10:05 AM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.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
В списке pgsql-hackers по дате отправления: