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.

Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>

1 files changed, 6 insertions, 1 deletions

diff --git a/src/backend/executor/nodeIndexscan.c b/src/backend/executor/nodeIndexscan.c
index 758fabdefe5..b8acb7897b4 100644
--- a/src/backend/executor/nodeIndexscan.c
+++ b/src/backend/executor/nodeIndexscan.c
@@ -7,7 +7,7 @@
  *
  *
  * IDENTIFICATION
- *    $Header: /cvsroot/pgsql/src/backend/executor/nodeIndexscan.c,v 1.1.1.1 1996/07/09 06:21:26 scrappy Exp $
+ *    $Header: /cvsroot/pgsql/src/backend/executor/nodeIndexscan.c,v 1.2 1996/10/30 06:08:10 scrappy Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -273,6 +273,11 @@ ExecIndexReScan(IndexScan *node, ExprContext *exprCtxt, Plan* parent)
 		scanvalue = (Datum)
 		    ExecEvalExpr(scanexpr, exprCtxt, &isNull, &isDone);
 		scan_keys[j].sk_argument = scanvalue;
+		if (isNull) {
+		    scan_keys[j].sk_flags |= SK_ISNULL;
+		} else {
+		    scan_keys[j].sk_flags &= ~SK_ISNULL;
+		}
 	    }
 	}
     }