More btree fixes from Massimo Dal Zotto <dz@cs.unitn.it>

Fixes:

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.

1 files changed, 5 insertions, 1 deletions

diff --git a/src/backend/access/common/heapvalid.c b/src/backend/access/common/heapvalid.c
index b80c5dd9eb0..535ed67e731 100644
--- a/src/backend/access/common/heapvalid.c
+++ b/src/backend/access/common/heapvalid.c
@@ -7,7 +7,7 @@
  *
  *
  * IDENTIFICATION
- *    $Header: /cvsroot/pgsql/src/backend/access/common/Attic/heapvalid.c,v 1.1.1.1 1996/07/09 06:21:09 scrappy Exp $
+ *    $Header: /cvsroot/pgsql/src/backend/access/common/Attic/heapvalid.c,v 1.1.1.1.2.1 1996/10/30 06:06:36 scrappy Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -54,6 +54,10 @@ heap_keytest(HeapTuple t,
 	    /* XXX eventually should check if SK_ISNULL */
 	    return false;
 	
+	if (keys->sk_flags & SK_ISNULL) {
+	    return (false);
+	}
+
 	if (keys->sk_flags & SK_COMMUTE)
 	    test = (long) FMGR_PTR2(keys->sk_func, keys->sk_procedure,
 				    keys->sk_argument, atp);