aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/nbtree/nbtutils.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2011-06-29 19:46:47 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2011-06-29 19:46:47 -0400
commita5652d3e05380edcd35236e94b924c8c105eaefd (patch)
tree55a1000384869836f18e1236feb3f7477c05db3e /src/backend/access/nbtree/nbtutils.c
parentcd70dd6bef515a573a5af1756ce6a8b8406bb5d4 (diff)
downloadpostgresql-a5652d3e05380edcd35236e94b924c8c105eaefd.tar.gz
postgresql-a5652d3e05380edcd35236e94b924c8c105eaefd.zip
Restore correct btree preprocessing of "indexedcol IS NULL" conditions.
Such a condition is unsatisfiable in combination with any other type of btree-indexable condition (since we assume btree operators are always strict). 8.3 and 8.4 had an explicit test for this, which I removed in commit 29c4ad98293e3c5cb3fcdd413a3f4904efff8762, mistakenly thinking that the case would be subsumed by the more general handling of IS (NOT) NULL added in that patch. Put it back, and improve the comments about it, and add a regression test case. Per bug #6079 from Renat Nasyrov, and analysis by Dean Rasheed.
Diffstat (limited to 'src/backend/access/nbtree/nbtutils.c')
-rw-r--r--src/backend/access/nbtree/nbtutils.c17
1 files changed, 15 insertions, 2 deletions
diff --git a/src/backend/access/nbtree/nbtutils.c b/src/backend/access/nbtree/nbtutils.c
index 2e896a258f7..f87eadcdec2 100644
--- a/src/backend/access/nbtree/nbtutils.c
+++ b/src/backend/access/nbtree/nbtutils.c
@@ -325,8 +325,14 @@ _bt_preprocess_keys(IndexScanDesc scan)
/*
* If = has been specified, all other keys can be eliminated as
- * redundant. In case of key > 2 && key == 1 we can set qual_ok
- * to false and abandon further processing.
+ * redundant. If we have a case like key = 1 AND key > 2, we can
+ * set qual_ok to false and abandon further processing.
+ *
+ * We also have to deal with the case of "key IS NULL", which is
+ * unsatisfiable in combination with any other index condition.
+ * By the time we get here, that's been classified as an equality
+ * check, and we've rejected any combination of it with a regular
+ * equality condition; but not with other types of conditions.
*/
if (xform[BTEqualStrategyNumber - 1])
{
@@ -339,6 +345,13 @@ _bt_preprocess_keys(IndexScanDesc scan)
if (!chk || j == (BTEqualStrategyNumber - 1))
continue;
+ if (eq->sk_flags & SK_SEARCHNULL)
+ {
+ /* IS NULL is contradictory to anything else */
+ so->qual_ok = false;
+ return;
+ }
+
if (_bt_compare_scankey_args(scan, chk, eq, chk,
&test_result))
{