Обсуждение: [PATCH] Fix select from wrong table array_op_test

In the middle of GIN index testing, there are some selects that are on
a different table array_op_test that doesn't even have an index.  They
probably were supposed to be selects to table array_index_op_test like
the other ones around the area.

Fix that.  The expected output should stay the same because both tables
use the same array.data.
---
 src/test/regress/expected/create_index.out | 12 ++++++------
 src/test/regress/sql/create_index.sql      | 12 ++++++------
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/src/test/regress/expected/create_index.out b/src/test/regress/expected/create_index.out
index 49f2a158c1..cfdf73179f 100644
--- a/src/test/regress/expected/create_index.out
+++ b/src/test/regress/expected/create_index.out
@@ -904,23 +904,23 @@ SELECT * FROM array_index_op_test WHERE i <@ '{}' ORDER BY seqno;
    101 | {} | {}
 (1 row)
 
-SELECT * FROM array_op_test WHERE i = '{NULL}' ORDER BY seqno;
+SELECT * FROM array_index_op_test WHERE i = '{NULL}' ORDER BY seqno;
  seqno |   i    |   t    
 -------+--------+--------
    102 | {NULL} | {NULL}
 (1 row)
 
-SELECT * FROM array_op_test WHERE i @> '{NULL}' ORDER BY seqno;
+SELECT * FROM array_index_op_test WHERE i @> '{NULL}' ORDER BY seqno;
  seqno | i | t 
 -------+---+---
 (0 rows)
 
-SELECT * FROM array_op_test WHERE i && '{NULL}' ORDER BY seqno;
+SELECT * FROM array_index_op_test WHERE i && '{NULL}' ORDER BY seqno;
  seqno | i | t 
 -------+---+---
 (0 rows)
 
-SELECT * FROM array_op_test WHERE i <@ '{NULL}' ORDER BY seqno;
+SELECT * FROM array_index_op_test WHERE i <@ '{NULL}' ORDER BY seqno;
  seqno | i  | t  
 -------+----+----
    101 | {} | {}
@@ -1195,13 +1195,13 @@ SELECT * FROM array_index_op_test WHERE t = '{}' ORDER BY seqno;
    101 | {} | {}
 (1 row)
 
-SELECT * FROM array_op_test WHERE i = '{NULL}' ORDER BY seqno;
+SELECT * FROM array_index_op_test WHERE i = '{NULL}' ORDER BY seqno;
  seqno |   i    |   t    
 -------+--------+--------
    102 | {NULL} | {NULL}
 (1 row)
 
-SELECT * FROM array_op_test WHERE i <@ '{NULL}' ORDER BY seqno;
+SELECT * FROM array_index_op_test WHERE i <@ '{NULL}' ORDER BY seqno;
  seqno | i  | t  
 -------+----+----
    101 | {} | {}
diff --git a/src/test/regress/sql/create_index.sql b/src/test/regress/sql/create_index.sql
index 8bc76f7c6f..9474dabf9e 100644
--- a/src/test/regress/sql/create_index.sql
+++ b/src/test/regress/sql/create_index.sql
@@ -295,10 +295,10 @@ SELECT * FROM array_index_op_test WHERE i = '{}' ORDER BY seqno;
 SELECT * FROM array_index_op_test WHERE i @> '{}' ORDER BY seqno;
 SELECT * FROM array_index_op_test WHERE i && '{}' ORDER BY seqno;
 SELECT * FROM array_index_op_test WHERE i <@ '{}' ORDER BY seqno;
-SELECT * FROM array_op_test WHERE i = '{NULL}' ORDER BY seqno;
-SELECT * FROM array_op_test WHERE i @> '{NULL}' ORDER BY seqno;
-SELECT * FROM array_op_test WHERE i && '{NULL}' ORDER BY seqno;
-SELECT * FROM array_op_test WHERE i <@ '{NULL}' ORDER BY seqno;
+SELECT * FROM array_index_op_test WHERE i = '{NULL}' ORDER BY seqno;
+SELECT * FROM array_index_op_test WHERE i @> '{NULL}' ORDER BY seqno;
+SELECT * FROM array_index_op_test WHERE i && '{NULL}' ORDER BY seqno;
+SELECT * FROM array_index_op_test WHERE i <@ '{NULL}' ORDER BY seqno;
 
 CREATE INDEX textarrayidx ON array_index_op_test USING gin (t);
 
@@ -331,8 +331,8 @@ SELECT * FROM array_index_op_test WHERE t && '{AAAAAAA80240}' ORDER BY seqno;
 SELECT * FROM array_index_op_test WHERE i @> '{32}' AND t && '{AAAAAAA80240}' ORDER BY seqno;
 SELECT * FROM array_index_op_test WHERE i && '{32}' AND t @> '{AAAAAAA80240}' ORDER BY seqno;
 SELECT * FROM array_index_op_test WHERE t = '{}' ORDER BY seqno;
-SELECT * FROM array_op_test WHERE i = '{NULL}' ORDER BY seqno;
-SELECT * FROM array_op_test WHERE i <@ '{NULL}' ORDER BY seqno;
+SELECT * FROM array_index_op_test WHERE i = '{NULL}' ORDER BY seqno;
+SELECT * FROM array_index_op_test WHERE i <@ '{NULL}' ORDER BY seqno;
 
 RESET enable_seqscan;
 RESET enable_indexscan;
-- 
2.24.1

Jason Kim <git@jasonk.me> writes:
> In the middle of GIN index testing, there are some selects that are on
> a different table array_op_test that doesn't even have an index.  They
> probably were supposed to be selects to table array_index_op_test like
> the other ones around the area.

I think it's probably intentional, else why have two tables at all?
I suppose the point of these test cases is to confirm that you get the
same results with or without use of an index.

Certainly, there's more than one way to do that.  Perhaps we should
have only one table and perform the variant tests by manipulating
enable_indexscan et al.  But I think what you did here is defeating
the intent.

            regards, tom lane

On 11/06/2021 18:31, Tom Lane wrote:
> Jason Kim <git@jasonk.me> writes:
>> In the middle of GIN index testing, there are some selects that are on
>> a different table array_op_test that doesn't even have an index.  They
>> probably were supposed to be selects to table array_index_op_test like
>> the other ones around the area.
> 
> I think it's probably intentional, else why have two tables at all?
> I suppose the point of these test cases is to confirm that you get the
> same results with or without use of an index.

We already have these same queries in the 'arrays' test against the 
'array_op_test' table, though. It sure looks like a copy-paste error to 
me as well.

- Heikki

On 2021-06-11T19:00:41+0300, Heikki Linnakangas wrote:
> We already have these same queries in the 'arrays' test against the
> 'array_op_test' table, though. It sure looks like a copy-paste error to me
> as well.

That's reason enough, but another reason is that I don't think GIN_CAT_NULL_KEY
is covered without this change.