Fix poorly written regression test

bd10ec529 added code to allow redundant functionally dependent GROUP BY
columns to be removed using unique indexes and NOT NULL constraints as
proofs of functional dependency.  In that commit, I (David) added a test
to ensure that when there are multiple indexes available to remove columns
that we pick the index that allows us to remove the most columns.  This
test was faulty as it assumed the t3 table's primary key index was valid
to use as functional dependency proof, but that's not the case since
that's defined as deferrable.

Here we adjust the tests added by that commit to use the t2 table instead.
That's defined with a non-deferrable primary key.

Author: songjinzhou <[email protected]>
Author: David Rowley <[email protected]>
Reviewed-by: Japin Li <[email protected]>
Discussion: https://postgr.es/m/[email protected]

1 files changed, 25 insertions, 25 deletions

diff --git a/src/test/regress/expected/aggregates.out b/src/test/regress/expected/aggregates.out
index f2fb66388cc..8c4f8ce27ed 100644
--- a/src/test/regress/expected/aggregates.out
+++ b/src/test/regress/expected/aggregates.out
@@ -1448,71 +1448,71 @@ explain (costs off) select * from p_t1 group by a,b,c,d;
          ->  Seq Scan on p_t1_2
 (5 rows)
 
-create unique index t3_c_uidx on t3(c);
+create unique index t2_z_uidx on t2(z);
 -- Ensure we don't remove any columns from the GROUP BY for a unique
 -- index on a NULLable column.
-explain (costs off) select b,c from t3 group by b,c;
+explain (costs off) select y,z from t2 group by y,z;
       QUERY PLAN      
 ----------------------
  HashAggregate
-   Group Key: b, c
-   ->  Seq Scan on t3
+   Group Key: y, z
+   ->  Seq Scan on t2
 (3 rows)
 
 -- Make the column NOT NULL and ensure we remove the redundant column
-alter table t3 alter column c set not null;
-explain (costs off) select b,c from t3 group by b,c;
+alter table t2 alter column z set not null;
+explain (costs off) select y,z from t2 group by y,z;
       QUERY PLAN      
 ----------------------
  HashAggregate
-   Group Key: c
-   ->  Seq Scan on t3
+   Group Key: z
+   ->  Seq Scan on t2
 (3 rows)
 
 -- When there are multiple supporting unique indexes and the GROUP BY contains
 -- columns to cover all of those, ensure we pick the index with the least
 -- number of columns so that we can remove more columns from the GROUP BY.
-explain (costs off) select a,b,c from t3 group by a,b,c;
+explain (costs off) select x,y,z from t2 group by x,y,z;
       QUERY PLAN      
 ----------------------
  HashAggregate
-   Group Key: c
-   ->  Seq Scan on t3
+   Group Key: z
+   ->  Seq Scan on t2
 (3 rows)
 
 -- As above but try ordering the columns differently to ensure we get the
 -- same result.
-explain (costs off) select a,b,c from t3 group by c,a,b;
+explain (costs off) select x,y,z from t2 group by z,x,y;
       QUERY PLAN      
 ----------------------
  HashAggregate
-   Group Key: c
-   ->  Seq Scan on t3
+   Group Key: z
+   ->  Seq Scan on t2
 (3 rows)
 
 -- Ensure we don't use a partial index as proof of functional dependency
-drop index t3_c_uidx;
-create index t3_c_uidx on t3 (c) where c > 0;
-explain (costs off) select b,c from t3 group by b,c;
+drop index t2_z_uidx;
+create index t2_z_uidx on t2 (z) where z > 0;
+explain (costs off) select y,z from t2 group by y,z;
       QUERY PLAN      
 ----------------------
  HashAggregate
-   Group Key: b, c
-   ->  Seq Scan on t3
+   Group Key: y, z
+   ->  Seq Scan on t2
 (3 rows)
 
 -- A unique index defined as NULLS NOT DISTINCT does not need a supporting NOT
 -- NULL constraint on the indexed columns.  Ensure the redundant columns are
 -- removed from the GROUP BY for such a table.
-drop index t3_c_uidx;
-alter table t3 alter column c drop not null;
-create unique index t3_c_uidx on t3(c) nulls not distinct;
-explain (costs off) select b,c from t3 group by b,c;
+drop index t2_z_uidx;
+alter table t2 alter column z drop not null;
+create unique index t2_z_uidx on t2(z) nulls not distinct;
+explain (costs off) select y,z from t2 group by y,z;
       QUERY PLAN      
 ----------------------
  HashAggregate
-   Group Key: c
-   ->  Seq Scan on t3
+   Group Key: z
+   ->  Seq Scan on t2
 (3 rows)
 
 drop table t1 cascade;