From 69c7f25bed1a3dc1a8343b60411d8d9884cfc956 Mon Sep 17 00:00:00 2001 From: "Marc G. Fournier" Date: Wed, 30 Oct 1996 06:08:10 +0000 Subject: 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 --- src/backend/access/common/heapvalid.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'src/backend/access/common/heapvalid.c') diff --git a/src/backend/access/common/heapvalid.c b/src/backend/access/common/heapvalid.c index 45003095b2..c50700c203 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.6 1996/10/21 11:49:36 scrappy Exp $ + * $Header: /cvsroot/pgsql/src/backend/access/common/Attic/heapvalid.c,v 1.7 1996/10/30 06:07:56 scrappy Exp $ * *------------------------------------------------------------------------- */ @@ -71,6 +71,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); -- cgit v1.2.1