On 12/02/2012 11:29 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 12/02/2012 10:05 AM, Tom Lane wrote:
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 installch
Andrew Dunstan writes:
> On 12/02/2012 10:05 AM, Tom Lane wrote:
>> 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
On 12/02/2012 10:05 AM, Tom Lane wrote:
Andrew Dunstan 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
Andrew Dunstan 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 do
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. The reason is that this will let us test upgrading them using
pg_upgrade much more easily. Not testing this is a significant hole in
the pg_upgrade
