]> git.ipfire.org Git - thirdparty/postgresql.git/commitdiff
More bogosity in alter_table test: sometimes causes prepare test to fail
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 23 Dec 2003 20:34:51 +0000 (20:34 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 23 Dec 2003 20:34:51 +0000 (20:34 +0000)
by means of arbitrarily renaming tables the other test depends on.

src/test/regress/expected/alter_table.out
src/test/regress/sql/alter_table.sql

index 250f6a77c6a17a35f62f666483aa9a01fd35a628..c5eff5e943374afdbfdb56d609708c9b13af02bc 100644 (file)
@@ -90,183 +90,36 @@ SELECT * FROM tmp;
 
 DROP TABLE tmp;
 --
--- rename -
---   should preserve indices, which we can check by seeing if a SELECT
---   chooses an indexscan; however, in the absence of vacuum statistics
---   it might not.  Therefore, vacuum first.
+-- rename - check on both non-temp and temp tables
 --
-VACUUM ANALYZE tenk1;
-ALTER TABLE tenk1 RENAME TO ten_k;
--- 20 values, sorted 
-SELECT unique1 FROM ten_k WHERE unique1 < 20;
- unique1 
----------
-       0
-       1
-       2
-       3
-       4
-       5
-       6
-       7
-       8
-       9
-      10
-      11
-      12
-      13
-      14
-      15
-      16
-      17
-      18
-      19
-(20 rows)
+CREATE TABLE tmp (regtable int);
+CREATE TEMP TABLE tmp (tmptable int);
+ALTER TABLE tmp RENAME TO tmp_new;
+SELECT * FROM tmp;
+ regtable 
+----------
+(0 rows)
 
--- 20 values, sorted 
-SELECT unique2 FROM ten_k WHERE unique2 < 20;
- unique2 
----------
-       0
-       1
-       2
-       3
-       4
-       5
-       6
-       7
-       8
-       9
-      10
-      11
-      12
-      13
-      14
-      15
-      16
-      17
-      18
-      19
-(20 rows)
+SELECT * FROM tmp_new;
+ tmptable 
+----------
+(0 rows)
 
--- 100 values, sorted 
-SELECT hundred FROM ten_k WHERE hundred = 50;
- hundred 
----------
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-      50
-(100 rows)
+ALTER TABLE tmp RENAME TO tmp_new2;
+SELECT * FROM tmp;             -- should fail
+ERROR:  relation "tmp" does not exist
+SELECT * FROM tmp_new;
+ tmptable 
+----------
+(0 rows)
 
-ALTER TABLE ten_k RENAME TO tenk1;
--- 5 values, sorted 
-SELECT unique1 FROM tenk1 WHERE unique1 < 5;
- unique1 
----------
-       0
-       1
-       2
-       3
-       4
-(5 rows)
+SELECT * FROM tmp_new2;
+ regtable 
+----------
+(0 rows)
 
+DROP TABLE tmp_new;
+DROP TABLE tmp_new2;
 -- ALTER TABLE ... RENAME on non-table relations
 -- renaming indexes (FIXME: this should probably test the index's functionality)
 ALTER TABLE onek_unique1 RENAME TO tmp_onek_unique1;
@@ -274,6 +127,8 @@ ALTER TABLE tmp_onek_unique1 RENAME TO onek_unique1;
 -- renaming views
 CREATE VIEW tmp_view (unique1) AS SELECT unique1 FROM tenk1;
 ALTER TABLE tmp_view RENAME TO tmp_view_new;
+-- analyze to ensure we get an indexscan here
+ANALYZE tenk1;
 -- 5 values, sorted 
 SELECT unique1 FROM tenk1 WHERE unique1 < 5;
  unique1 
index ef91f02b511da21be4c0e70e9619b713aa986e50..6d5d23591cdc8036a33406f5fb7479cc2b6e88b7 100644 (file)
@@ -140,28 +140,25 @@ DROP TABLE tmp;
 
 
 --
--- rename -
---   should preserve indices, which we can check by seeing if a SELECT
---   chooses an indexscan; however, in the absence of vacuum statistics
---   it might not.  Therefore, vacuum first.
+-- rename - check on both non-temp and temp tables
 --
-VACUUM ANALYZE tenk1;
+CREATE TABLE tmp (regtable int);
+CREATE TEMP TABLE tmp (tmptable int);
 
-ALTER TABLE tenk1 RENAME TO ten_k;
+ALTER TABLE tmp RENAME TO tmp_new;
 
--- 20 values, sorted 
-SELECT unique1 FROM ten_k WHERE unique1 < 20;
+SELECT * FROM tmp;
+SELECT * FROM tmp_new;
 
--- 20 values, sorted 
-SELECT unique2 FROM ten_k WHERE unique2 < 20;
+ALTER TABLE tmp RENAME TO tmp_new2;
 
--- 100 values, sorted 
-SELECT hundred FROM ten_k WHERE hundred = 50;
+SELECT * FROM tmp;             -- should fail
+SELECT * FROM tmp_new;
+SELECT * FROM tmp_new2;
 
-ALTER TABLE ten_k RENAME TO tenk1;
+DROP TABLE tmp_new;
+DROP TABLE tmp_new2;
 
--- 5 values, sorted 
-SELECT unique1 FROM tenk1 WHERE unique1 < 5;
 
 -- ALTER TABLE ... RENAME on non-table relations
 -- renaming indexes (FIXME: this should probably test the index's functionality)
@@ -170,6 +167,8 @@ ALTER TABLE tmp_onek_unique1 RENAME TO onek_unique1;
 -- renaming views
 CREATE VIEW tmp_view (unique1) AS SELECT unique1 FROM tenk1;
 ALTER TABLE tmp_view RENAME TO tmp_view_new;
+-- analyze to ensure we get an indexscan here
+ANALYZE tenk1;
 -- 5 values, sorted 
 SELECT unique1 FROM tenk1 WHERE unique1 < 5;
 DROP VIEW tmp_view_new;