/ Check-in [da81725c]
Login
☰Home Timeline Branches

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Clarify the documentation on how comparisons occur in an IN operator. Fix the comparison operators when both sides of an IN operator are expressions (ticket #2248). Changes to main.mk for adding FTS2 into the standard build also got mixed in with this check-in by mistake. (CVS 3656)
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: da81725ca1cd894b3f2d734767e10cc0dc329566
User & Date: drh 2007-02-23 03:00:45
Context
2007-02-23
14:20
Clarifications to the datatype3.html document. (CVS 3657) (check-in: 4692a85e user: drh tags: trunk)
03:00
Clarify the documentation on how comparisons occur in an IN operator. Fix the comparison operators when both sides of an IN operator are expressions (ticket #2248). Changes to main.mk for adding FTS2 into the standard build also got mixed in with this check-in by mistake. (CVS 3656) (check-in: da81725c user: drh tags: trunk)
00:14
Fix typos in test naming (was using 'e' instead of 'f'). (CVS 3655) (check-in: 16cb00ad user: shess tags: trunk)
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to main.mk. 

97
98
99
100
101
102
103

104
105
106
107
108
109
110
...
126
127
128
129
130
131
132


















133
134
135
136
137
138
139
...
178
179
180
181
182
183
184
185
186
187
188




189
190
191
192
193
194
195
196
197
198
199
200
201
...
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
...
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396

  $(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/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




















# 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
#
HDR += \
  $(TOP)/ext/fts1/fts1.h \
  $(TOP)/ext/fts1/fts1_hash.h \
  $(TOP)/ext/fts1/fts1_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.
#
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) $(VDBEHDR) opcodes.c keywordhash.h
	rm -rf tsrc
	mkdir tsrc
	cp $(SRC) $(VDBEHDR) 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
	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)
	$(TCCX) -c $(TOP)/src/vdbe.c

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

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

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

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

vtab.o:	$(TOP)/src/vtab.c $(VDBEHDR)
	$(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
#








>







 







>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







 







|



>
>
>
>





<







 







|


|

<







 







|


|


|


|


|


|








97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
...
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
...
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216

217
218
219
220
221
222
223
...
240
241
242
243
244
245
246
247
248
249
250
251

252
253
254
255
256
257
258
...
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417

  $(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
#

Changes to src/expr.c. 

8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
...
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141

**    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.276 2007/02/14 09:19:36 danielk1977 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_NUMERIC;
  }
  return aff;
}

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








|







 







|








8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
...
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141

**    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

Changes to test/types2.test. 

8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
...
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
...
225
226
227
228
229
230
231



























232
233
234
235
236
237
238

#    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.6 2006/05/23 23:22:29 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)} 1
  
  # 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



























}

# 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']








|







 







|







 







>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>








8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
...
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
...
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265

#    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']

Changes to www/datatype3.tcl. 

1
2
3
4
5
6
7
8
...
221
222
223
224
225
226
227
228
229




230
231
232
233
234
235
236

set rcsid {$Id: datatype3.tcl,v 1.14 2006/05/23 23:22:29 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 = z OR
a = y OR a = z".




</P>

<h4>3.1 Comparison Example</h4>

<blockquote>
<PRE>
CREATE TABLE t1(

|







 







|
|
>
>
>
>








1
2
3
4
5
6
7
8
...
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240

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(

This page was generated in about 0.042s by Fossil 2.13 [6a6fd6b911] 2020-10-29 19:18:56