NULL values are distinct. A comparison involving a NULL is always false.

Operations on a NULL value yield a NULL result.  This change makes SQLite
operate more like the SQL spec, but it may break existing applications that
assumed the old behavior.  All the old tests pass but we still need to add
new tests to better verify the new behavior.  Fix for ticket #44. (CVS 589)

FossilOrigin-Name: 9051173742f1b0e15a809d12a0c9c98fd2c4614d

1 files changed, 3 insertions, 3 deletions

diff --git a/src/where.c b/src/where.c
index a3576cae4..0f14df9de 100644
--- a/src/where.c
+++ b/src/where.c
@@ -13,7 +13,7 @@
 ** the WHERE clause of SQL statements.  Also found here are subroutines
 ** to generate VDBE code to evaluate expressions.
 **
-** $Id: where.c,v 1.47 2002/05/24 20:31:38 drh Exp $
+** $Id: where.c,v 1.48 2002/05/26 20:54:34 drh Exp $
 */
 #include "sqliteInt.h"
 
@@ -199,7 +199,7 @@ WhereInfo *sqliteWhereBegin(
   ** expression and either jump over all of the code or fall thru.
   */
   if( pWhere && sqliteExprIsConstant(pWhere) ){
-    sqliteExprIfFalse(pParse, pWhere, pWInfo->iBreak);
+    sqliteExprIfFalse(pParse, pWhere, pWInfo->iBreak, 1);
   }
 
   /* Split the WHERE clause into as many as 32 separate subexpressions
@@ -795,7 +795,7 @@ WhereInfo *sqliteWhereBegin(
         haveKey = 0;
         sqliteVdbeAddOp(v, OP_MoveTo, base+idx, 0);
       }
-      sqliteExprIfFalse(pParse, aExpr[j].p, cont);
+      sqliteExprIfFalse(pParse, aExpr[j].p, cont, 1);
       aExpr[j].p = 0;
     }
     brk = cont;