Re: dropping table in testcase alter_table.sql

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: 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 09:46:09
Message-ID: 1310463969.5488.3.camel@fsopti579.F-Secure.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On fre, 2011-07-08 at 22:27 -0400, Robert Haas wrote:
> On Fri, Jul 8, 2011 at 1:45 AM, Ashutosh Bapat
> <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
> > I think, tab1 and tab2 are too common names, for anyone to pick up for the
> > tables. Also, the test alter_table.sql is dropping many other tables (even
> > those which have undergone renaming), then why not these two?
>
> Beats me, but I don't see any particular value to changing it.

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2011-07-12 09:53:52 Re: [v9.2] DROP Reworks Part.1 - Consolidate routines to handle DropStmt
Previous Message Florian Pflug 2011-07-12 09:45:59 Re: Patch Review: Bugfix for XPATH() if text or attribute nodes are selected