Re: dropping table in testcase alter_table.sql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dropping table in testcase alter_table.sql
Date: 2011-07-12 12:51:31
Message-ID: 10216.1310475091@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> It has occurred to me a few times that it could be useful to clarify the
> approach here. If we could somehow have a separable cleanup step for
> every test, and eliminate interdependencies between tests, we could more
> easily support a number of uses cases such as creating a completely
> populated regression test database for playing, or running tests in
> random order or in differently parallelized scenarios.

The limiting case of this is that each regression test script would be
expected to start in an empty database and leave the DB empty on exit.
I think that would make the tests less useful, not more, for several
reasons:

1. They'd be slower, since every test would have to start by creating
and populating some tables.

2. The final state of the regression database would no longer be useful
as an environment for running ad-hoc manual tests.

3. The final state of the regression database would no longer be useful
as a test case for pg_dump and pg_upgrade.

The ALTER TABLE tests are particularly useful in connection with #3,
because they leave around tables that have been modified in various
ways. I'm not sure that the particular tables in question here are
of any great value for stressing pg_dump, but in general I'd not want
to see a push to make alter_table.sql clean up after itself.

We could of course address all these issues in some more-formal way.
But I don't think it's a good idea to say "let's make the regression
tests less messy" without understanding that they have these additional
use-cases that have to be catered for somehow.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-07-12 12:55:57 Re: reducing the overhead of frequent table locks, v4
Previous Message Robert Haas 2011-07-12 12:26:59 Re: [COMMITTERS] pgsql: Enable CHECK constraints to be declared NOT VALID