Index: main.mk ================================================================== --- main.mk +++ main.mk @@ -99,10 +99,11 @@ $(TOP)/src/printf.c \ $(TOP)/src/random.c \ $(TOP)/src/select.c \ $(TOP)/src/shell.c \ $(TOP)/src/sqlite.h.in \ + $(TOP)/src/sqlite3ext.h \ $(TOP)/src/sqliteInt.h \ $(TOP)/src/table.c \ $(TOP)/src/tclsqlite.c \ $(TOP)/src/tokenize.c \ $(TOP)/src/trigger.c \ @@ -128,10 +129,28 @@ $(TOP)/ext/fts1/fts1_hash.c \ $(TOP)/ext/fts1/fts1_hash.h \ $(TOP)/ext/fts1/fts1_porter.c \ $(TOP)/ext/fts1/fts1_tokenizer.h \ $(TOP)/ext/fts1/fts1_tokenizer1.c +SRC += \ + $(TOP)/ext/fts2/fts2.c \ + $(TOP)/ext/fts2/fts2.h \ + $(TOP)/ext/fts2/fts2_hash.c \ + $(TOP)/ext/fts2/fts2_hash.h \ + $(TOP)/ext/fts2/fts2_porter.c \ + $(TOP)/ext/fts2/fts2_tokenizer.h \ + $(TOP)/ext/fts2/fts2_tokenizer1.c + +# Generated source code files +# +SRC += \ + keywordhash.h \ + opcodes.c \ + opcodes.h \ + parse.c \ + parse.h \ + sqlite3.h # Source code to the test files. # TESTSRC = \ @@ -180,20 +199,23 @@ $(TOP)/src/vdbe.h \ parse.h # Header files used by extensions # -HDR += \ +EXTHDR += \ $(TOP)/ext/fts1/fts1.h \ $(TOP)/ext/fts1/fts1_hash.h \ $(TOP)/ext/fts1/fts1_tokenizer.h +EXTHDR += \ + $(TOP)/ext/fts2/fts2.h \ + $(TOP)/ext/fts2/fts2_hash.h \ + $(TOP)/ext/fts2/fts2_tokenizer.h # Header files used by the VDBE submodule # VDBEHDR = \ - $(HDR) \ $(TOP)/src/vdbeInt.h # This is the default Makefile target. The objects listed here # are what get build when you type just "make" with no arguments. # @@ -220,16 +242,15 @@ # copies of all of the C source code and header files needed to # build on the target system. Some of the C source code and header # files are automatically generated. This target takes care of # all that automatic generation. # -target_source: $(SRC) $(VDBEHDR) opcodes.c keywordhash.h +target_source: $(SRC) rm -rf tsrc mkdir tsrc - cp $(SRC) $(VDBEHDR) tsrc + cp $(SRC) tsrc rm tsrc/sqlite.h.in tsrc/parse.y - cp parse.c opcodes.c keywordhash.h tsrc # Rules to build the LEMON compiler generator # lemon: $(TOP)/tool/lemon.c $(TOP)/tool/lempar.c $(BCC) -o lemon $(TOP)/tool/lemon.c @@ -369,26 +390,26 @@ $(TCCX) -c $(TOP)/src/util.c vacuum.o: $(TOP)/src/vacuum.c $(HDR) $(TCCX) -c $(TOP)/src/vacuum.c -vdbe.o: $(TOP)/src/vdbe.c $(VDBEHDR) +vdbe.o: $(TOP)/src/vdbe.c $(VDBEHDR) $(HDR) $(TCCX) -c $(TOP)/src/vdbe.c -vdbeapi.o: $(TOP)/src/vdbeapi.c $(VDBEHDR) +vdbeapi.o: $(TOP)/src/vdbeapi.c $(VDBEHDR) $(HDR) $(TCCX) -c $(TOP)/src/vdbeapi.c -vdbeaux.o: $(TOP)/src/vdbeaux.c $(VDBEHDR) +vdbeaux.o: $(TOP)/src/vdbeaux.c $(VDBEHDR) $(HDR) $(TCCX) -c $(TOP)/src/vdbeaux.c -vdbefifo.o: $(TOP)/src/vdbefifo.c $(VDBEHDR) +vdbefifo.o: $(TOP)/src/vdbefifo.c $(VDBEHDR) $(HDR) $(TCCX) -c $(TOP)/src/vdbefifo.c -vdbemem.o: $(TOP)/src/vdbemem.c $(VDBEHDR) +vdbemem.o: $(TOP)/src/vdbemem.c $(VDBEHDR) $(HDR) $(TCCX) -c $(TOP)/src/vdbemem.c -vtab.o: $(TOP)/src/vtab.c $(VDBEHDR) +vtab.o: $(TOP)/src/vtab.c $(VDBEHDR) $(HDR) $(TCCX) -c $(TOP)/src/vtab.c where.o: $(TOP)/src/where.c $(HDR) $(TCCX) -c $(TOP)/src/where.c Index: src/expr.c ================================================================== --- src/expr.c +++ src/expr.c @@ -10,11 +10,11 @@ ** ************************************************************************* ** This file contains routines used for analyzing expressions and ** for generating VDBE code that evaluates expressions in SQLite. ** -** $Id: expr.c,v 1.276 2007/02/14 09:19:36 danielk1977 Exp $ +** $Id: expr.c,v 1.277 2007/02/23 03:00:45 drh Exp $ */ #include "sqliteInt.h" #include /* @@ -129,11 +129,11 @@ } else if( pExpr->pSelect ){ aff = sqlite3CompareAffinity(pExpr->pSelect->pEList->a[0].pExpr, aff); } else if( !aff ){ - aff = SQLITE_AFF_NUMERIC; + aff = SQLITE_AFF_NONE; } return aff; } /* Index: test/types2.test ================================================================== --- test/types2.test +++ test/types2.test @@ -10,11 +10,11 @@ #*********************************************************************** # This file implements regression tests for SQLite library. The focus # of this file is testing the interaction of manifest types, type affinity # and comparison expressions. # -# $Id: types2.test,v 1.6 2006/05/23 23:22:29 drh Exp $ +# $Id: types2.test,v 1.7 2007/02/23 03:00:45 drh Exp $ set testdir [file dirname $argv0] source $testdir/tester.tcl # Tests in this file are organized roughly as follows: @@ -202,11 +202,11 @@ # Compare literals against literals (no affinity applied) test_bool types2-5.1 {} {(NULL IN ('10.0', 20)) ISNULL} 1 test_bool types2-5.2 {} {10 IN ('10.0', 20)} 0 test_bool types2-5.3 {} {'10' IN ('10.0', 20)} 0 test_bool types2-5.4 {} {10 IN (10.0, 20)} 1 - test_bool types2-5.5 {} {'10.0' IN (10, 20)} 1 + test_bool types2-5.5 {} {'10.0' IN (10, 20)} 0 # Compare literals against a column with TEXT affinity test_bool types2-5.6 {t1='10.0'} {t1 IN (10.0, 20)} 1 test_bool types2-5.7 {t1='10.0'} {t1 IN (10, 20)} 0 test_bool types2-5.8 {t1='10'} {t1 IN (10.0, 20)} 0 @@ -227,10 +227,37 @@ test_bool types2-5.19 {o1='10'} {o1 IN (20, '10.0')} 0 test_bool types2-5.20 {o1=10} {o1 IN (20, '10')} 0 test_bool types2-5.21 {o1='10.0'} {o1 IN (10, 20, '10.0')} 1 test_bool types2-5.22 {o1='10'} {o1 IN (10.0, 20, '10')} 1 test_bool types2-5.23 {o1=10} {n1 IN (20, '10', 10)} 1 + + # Ticket #2248: Comparisons of strings literals that look like + # numbers. + test_bool types2-5.24 {} {'1' IN ('1')} 1 + test_bool types2-5.25 {} {'2' IN (2)} 0 + test_bool types2-5.26 {} {3 IN ('3')} 0 + test_bool types2-5.27 {} {4 IN (4)} 1 + + # The affinity of columns on the right side of IN(...) is ignored. + # All values in the expression list are treated as ordinary expressions, + # even if they are columns with affinity. + test_bool types2-5.30 {t1='10'} {10 IN (5,t1,'abc')} 0 + test_bool types2-5.31 {t1='10'} {10 IN ('abc',t1,5)} 0 + test_bool types2-5.32 {t1='010'} {10 IN (5,t1,'abc')} 0 + test_bool types2-5.33 {t1='010'} {10 IN ('abc',t1,5)} 0 + test_bool types2-5.34 {t1='10'} {'10' IN (5,t1,'abc')} 1 + test_bool types2-5.35 {t1='10'} {'10' IN ('abc',t1,5)} 1 + test_bool types2-5.36 {t1='010'} {'10' IN (5,t1,'abc')} 0 + test_bool types2-5.37 {t1='010'} {'10' IN ('abc',t1,5)} 0 + + # Columns on both the left and right of IN(...). Only the column + # on the left matters. The all values on the right are treated like + # expressions. + test_bool types2-5.40 {t1='10',n1=10} {t1 IN (5,n1,11)} 1 + test_bool types2-5.41 {t1='010',n1=10} {t1 IN (5,n1,11)} 0 + test_bool types2-5.42 {t1='10',n1=10} {n1 IN (5,t1,11)} 1 + test_bool types2-5.43 {t1='010',n1=10} {n1 IN (5,t1,11)} 1 } # Tests named types2-6.* use the same infrastructure as the types2-2.* # tests. The contents of the vals array is repeated here for easy # reference. Index: www/datatype3.tcl ================================================================== --- www/datatype3.tcl +++ www/datatype3.tcl @@ -1,6 +1,6 @@ -set rcsid {$Id: datatype3.tcl,v 1.14 2006/05/23 23:22:29 drh Exp $} +set rcsid {$Id: datatype3.tcl,v 1.15 2007/02/23 03:00:46 drh Exp $} source common.tcl header {Datatypes In SQLite Version 3} puts {

Datatypes In SQLite Version 3

@@ -223,12 +223,16 @@ rules enumerated above for binary comparisons (e.g. in a similar manner to "a = b"). For example if 'b' is a column value and 'a' is an expression, then the affinity of 'b' is applied to 'a' before any comparisons take place.

-

SQLite treats the expression "a IN (x, y, z)" as equivalent to "a = z OR -a = y OR a = z". +

SQLite treats the expression "a IN (x, y, z)" as equivalent to "a = +x OR +a = +y OR a = +z". The values to the right of the IN operator (the "x", "y", +and "z" values in this example) are considered to be expressions, even if they +happen to be column values. If the value of the left of the IN operator is +a column, then the affinity of that column is used. If the value is an +expression then no conversions occur.

3.1 Comparison Example