1
0
mirror of https://github.com/postgres/postgres.git synced 2025-11-10 17:42:29 +03:00
I found another bug in btree index.  Looking at the code it seems that NULL
keys are never used to build or scan a btree index (see the explain commands
in the example).  However this is not the case when a null key is retrieved
in an outer loop of a join select and used in an index scan of an inner loop.
This bug causes at least three kinds of problems:

1)  the backend crashes when it tries to compare a text string with a null.

2)  it is not possible to find tuples with null keys in a join.

3)  null is considered equal to 0 when the datum is passed by value, see
    the last query.

Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>
This commit is contained in:
Marc G. Fournier
1996-10-30 06:08:10 +00:00
parent 6ada9dfdce
commit 69c7f25bed
4 changed files with 43 additions and 5 deletions

View File

@@ -7,7 +7,7 @@
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/access/common/Attic/indexvalid.c,v 1.6 1996/10/21 11:49:38 scrappy Exp $
* $Header: /cvsroot/pgsql/src/backend/access/common/Attic/indexvalid.c,v 1.7 1996/10/30 06:07:55 scrappy Exp $
*
*-------------------------------------------------------------------------
*/
@@ -68,6 +68,10 @@ index_keytest(IndexTuple tuple,
return (false);
}
if (key[0].sk_flags & SK_ISNULL) {
return (false);
}
if (key[0].sk_flags & SK_COMMUTE) {
test = (int) (*(key[0].sk_func))
(DatumGetPointer(key[0].sk_argument),