dropping table in testcase alter_table.sql
Hi,
I noticed that the test alter_table.sql is creating two tables tab1 and tab2
and it's not dropping it. Any test which follows this test and tries to
create tables with names tab1 and tab2 will fail (unless it drops those
tables first, but that may not work, since tab2.y depends upon tab1 in
alter_table.sql).
PFA patch which drops these two tables from alter_table.sql and
corresponding OUT change. The regression run clean with this patch.
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
Attachments:
PGHEAD.patchtext/x-diff; charset=US-ASCII; name=PGHEAD.patchDownload
diff --git a/src/test/regress/expected/alter_table.out b/src/test/regress/expected/alter_table.out
index 9ab84f9..4f626dd 100644
--- a/src/test/regress/expected/alter_table.out
+++ b/src/test/regress/expected/alter_table.out
@@ -1503,20 +1503,22 @@ select * from another;
two more | 20
three more | 30
(3 rows)
drop table another;
-- table's row type
create table tab1 (a int, b text);
create table tab2 (x int, y tab1);
alter table tab1 alter column b type varchar; -- fails
ERROR: cannot alter table "tab1" because column "tab2.y" uses its row type
+drop table tab2;
+drop table tab1;
-- disallow recursive containment of row types
create temp table recur1 (f1 int);
alter table recur1 add column f2 recur1; -- fails
ERROR: composite type recur1 cannot be made a member of itself
alter table recur1 add column f2 recur1[]; -- fails
ERROR: composite type recur1 cannot be made a member of itself
create domain array_of_recur1 as recur1[];
alter table recur1 add column f2 array_of_recur1; -- fails
ERROR: composite type recur1 cannot be made a member of itself
create temp table recur2 (f1 int, f2 recur1);
diff --git a/src/test/regress/sql/alter_table.sql b/src/test/regress/sql/alter_table.sql
index b5d76ea..9d5ec63 100644
--- a/src/test/regress/sql/alter_table.sql
+++ b/src/test/regress/sql/alter_table.sql
@@ -1116,20 +1116,22 @@ alter table another
alter f2 type bigint using f1 * 10;
select * from another;
drop table another;
-- table's row type
create table tab1 (a int, b text);
create table tab2 (x int, y tab1);
alter table tab1 alter column b type varchar; -- fails
+drop table tab2;
+drop table tab1;
-- disallow recursive containment of row types
create temp table recur1 (f1 int);
alter table recur1 add column f2 recur1; -- fails
alter table recur1 add column f2 recur1[]; -- fails
create domain array_of_recur1 as recur1[];
alter table recur1 add column f2 array_of_recur1; -- fails
create temp table recur2 (f1 int, f2 recur1);
alter table recur1 add column f2 recur2; -- fails
alter table recur1 add column f2 int;
On Thu, Jul 7, 2011 at 3:05 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
I noticed that the test alter_table.sql is creating two tables tab1 and tab2
and it's not dropping it. Any test which follows this test and tries to
create tables with names tab1 and tab2 will fail (unless it drops those
tables first, but that may not work, since tab2.y depends upon tab1 in
alter_table.sql).PFA patch which drops these two tables from alter_table.sql and
corresponding OUT change. The regression run clean with this patch.
The regression tests leave lots of objects lying around in the
regression database... why drop these two, as opposed to any of the
others?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Jul 7, 2011 at 9:41 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Jul 7, 2011 at 3:05 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:I noticed that the test alter_table.sql is creating two tables tab1 and
tab2
and it's not dropping it. Any test which follows this test and tries to
create tables with names tab1 and tab2 will fail (unless it drops those
tables first, but that may not work, since tab2.y depends upon tab1 in
alter_table.sql).PFA patch which drops these two tables from alter_table.sql and
corresponding OUT change. The regression run clean with this patch.The regression tests leave lots of objects lying around in the
regression database... why drop these two, as opposed to any of the
others?
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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
On Fri, Jul 8, 2011 at 1:45 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On fre, 2011-07-08 at 22:27 -0400, Robert Haas wrote:
On Fri, Jul 8, 2011 at 1:45 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.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.
On Jul 12, 2011, at 4:46 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On fre, 2011-07-08 at 22:27 -0400, Robert Haas wrote:
On Fri, Jul 8, 2011 at 1:45 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.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.
True.
...Robert
Peter Eisentraut <peter_e@gmx.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
On tis, 2011-07-12 at 08:51 -0400, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.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.
I think you misunderstood what I was saying. I wanted take out the
cleanup parts out of all test cases and make it a choice whether to run
them. Right now we have a lot of test cases that clean up after
themselves, which is useful in some cases (testing the cleaning, for one
thing), but not useful for 2. and 3.
On Wed, Jul 13, 2011 at 2:53 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On tis, 2011-07-12 at 08:51 -0400, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.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 couldmore
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.
If the tests are leaving behind the objects unintentionally, we can not be
sure whether the state of the objects before upgrade/dump (or for that
matter anything else) is intentional. If one needs to test upgrade and dump
truly, the state of objects in the database, just before upgrading/dumping,
needs to be arrived in a controlled manner. IOW, if a test wants to leave
behind objects in certain state for some further testing, it should be
"intentional". May be those objects should be annotated so (say, in the
comments?). All the other objects be better cleaned up.
Said that, these particular two tables have very common names tab1 and tab2,
which someone can pick up easily, thus linking two testcases
unintentionally. So, at least we can make sure that if we use such common
names for the objects, we clean them up at the end of test. If some object
needs to be left behind we can give it a special name (say, the name
includes the test case name, like alter_tab_tab1), so that there is lesser
chance of interference with later tests. In case of #2 and #3 it also serves
the purpose
1. Identifying the testcase which created/manipulated these objects last
2. We can trace the things that affected this object, before it came to a
certain state.
This can be useful information in debugging problems.
I think you misunderstood what I was saying. I wanted take out the
cleanup parts out of all test cases and make it a choice whether to run
them. Right now we have a lot of test cases that clean up after
themselves, which is useful in some cases (testing the cleaning, for one
thing), but not useful for 2. and 3.
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company