SQLite

  $(TOP)/src/pragma.c \
  $(TOP)/src/prepare.c \
  $(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 \
  $(TOP)/src/utf.c \
  $(TOP)/src/update.c \

  $(TOP)/ext/fts1/fts1.c \
  $(TOP)/ext/fts1/fts1.h \
  $(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 = \
  $(TOP)/src/btree.c \
  $(TOP)/src/date.c \

   $(TOP)/src/sqlite3ext.h \
   $(TOP)/src/sqliteInt.h  \
   $(TOP)/src/vdbe.h \
   parse.h

# Header files used by extensions
#
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 = \

   $(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.
#
all:	sqlite3.h libsqlite3.a sqlite3$(EXE)

# This target creates a directory named "tsrc" and fills it with
# 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)
	rm -rf tsrc
	mkdir tsrc
	cp $(SRC) tsrc
	rm tsrc/sqlite.h.in tsrc/parse.y


# Rules to build the LEMON compiler generator
#
lemon:	$(TOP)/tool/lemon.c $(TOP)/tool/lempar.c
	$(BCC) -o lemon $(TOP)/tool/lemon.c
	cp $(TOP)/tool/lempar.c .

util.o:	$(TOP)/src/util.c $(HDR)
	$(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) $(HDR)
	$(TCCX) -c $(TOP)/src/vdbe.c

vdbeapi.o:	$(TOP)/src/vdbeapi.c $(VDBEHDR) $(HDR)
	$(TCCX) -c $(TOP)/src/vdbeapi.c

vdbeaux.o:	$(TOP)/src/vdbeaux.c $(VDBEHDR) $(HDR)
	$(TCCX) -c $(TOP)/src/vdbeaux.c

vdbefifo.o:	$(TOP)/src/vdbefifo.c $(VDBEHDR) $(HDR)
	$(TCCX) -c $(TOP)/src/vdbefifo.c

vdbemem.o:	$(TOP)/src/vdbemem.c $(VDBEHDR) $(HDR)
	$(TCCX) -c $(TOP)/src/vdbemem.c

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

# Rules for building test programs and for running tests
#

**    May you find forgiveness for yourself and forgive others.
**    May you share freely, never taking more than you give.
**
*************************************************************************
** This file contains routines used for analyzing expressions and
** for generating VDBE code that evaluates expressions in SQLite.
**
** $Id: expr.c,v 1.277 2007/02/23 03:00:45 drh Exp $
*/
#include "sqliteInt.h"
#include <ctype.h>

/*
** Return the 'affinity' of the expression pExpr if any.
**

  if( pExpr->pRight ){
    aff = sqlite3CompareAffinity(pExpr->pRight, aff);
  }
  else if( pExpr->pSelect ){
    aff = sqlite3CompareAffinity(pExpr->pSelect->pEList->a[0].pExpr, aff);
  }
  else if( !aff ){
    aff = SQLITE_AFF_NONE;
  }
  return aff;
}

/*
** pExpr is a comparison expression, eg. '=', '<', IN(...) etc.
** idx_affinity is the affinity of an indexed column. Return true

#    May you share freely, never taking more than you give.
#
#***********************************************************************
# 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.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:
#
# types2-1.*: The '=' operator in the absence of an index.

  # types2-5.* - The 'IN (x, y....)' operator with no index.
  # 
  # 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)} 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
  test_bool types2-5.9 {t1='10'} {t1 IN (20, '10.0')} 0
  test_bool types2-5.10 {t1=10} {t1 IN (20, '10')} 1

  test_bool types2-5.17 {o1='10.0'} {o1 IN (10, 20)} 0
  test_bool types2-5.18 {o1='10'} {o1 IN (10.0, 20)} 0
  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.
# 
# set vals [list 10 10.0 '10' '10.0' 20 20.0 '20' '20.0' 30 30.0 '30' '30.0']

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 {
<h2>Datatypes In SQLite Version 3</h2>

<h3>1. Storage Classes</h3>

<P>Expressions of the type "a IN (SELECT b ....)" are handled by the three
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.</P>

<P>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.
</P>

<h4>3.1 Comparison Example</h4>

<blockquote>
<PRE>
CREATE TABLE t1(