1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/os/persistentdata/persistentstorage/sqlite3api/TEST/TclScript/in3.test Fri Jun 15 03:10:57 2012 +0200
1.3 @@ -0,0 +1,289 @@
1.4 +# 2007 November 29
1.5 +#
1.6 +# The author disclaims copyright to this source code. In place of
1.7 +# a legal notice, here is a blessing:
1.8 +#
1.9 +# May you do good and not evil.
1.10 +# May you find forgiveness for yourself and forgive others.
1.11 +# May you share freely, never taking more than you give.
1.12 +#
1.13 +#***********************************************************************
1.14 +# This file tests the optimisations made in November 2007 of expressions
1.15 +# of the following form:
1.16 +#
1.17 +# <value> IN (SELECT <column> FROM <table>)
1.18 +#
1.19 +# $Id: in3.test,v 1.5 2008/08/04 03:51:24 danielk1977 Exp $
1.20 +
1.21 +set testdir [file dirname $argv0]
1.22 +source $testdir/tester.tcl
1.23 +
1.24 +ifcapable !subquery {
1.25 + finish_test
1.26 + return
1.27 +}
1.28 +
1.29 +# Return the number of OpenEphemeral instructions used in the
1.30 +# implementation of the sql statement passed as a an argument.
1.31 +#
1.32 +proc nEphemeral {sql} {
1.33 + set nEph 0
1.34 + foreach op [execsql "EXPLAIN $sql"] {
1.35 + if {$op eq "OpenEphemeral"} {incr nEph}
1.36 + }
1.37 + set nEph
1.38 +}
1.39 +
1.40 +# This proc works the same way as execsql, except that the number
1.41 +# of OpenEphemeral instructions used in the implementation of the
1.42 +# statement is inserted into the start of the returned list.
1.43 +#
1.44 +proc exec_neph {sql} {
1.45 + return [concat [nEphemeral $sql] [execsql $sql]]
1.46 +}
1.47 +
1.48 +do_test in3-1.1 {
1.49 + execsql {
1.50 + CREATE TABLE t1(a PRIMARY KEY, b);
1.51 + INSERT INTO t1 VALUES(1, 2);
1.52 + INSERT INTO t1 VALUES(3, 4);
1.53 + INSERT INTO t1 VALUES(5, 6);
1.54 + }
1.55 +} {}
1.56 +
1.57 +# All of these queries should avoid using a temp-table:
1.58 +#
1.59 +do_test in3-1.2 {
1.60 + exec_neph { SELECT rowid FROM t1 WHERE rowid IN (SELECT rowid FROM t1); }
1.61 +} {0 1 2 3}
1.62 +do_test in3-1.3 {
1.63 + exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a FROM t1); }
1.64 +} {0 1 3 5}
1.65 +do_test in3-1.4 {
1.66 + exec_neph { SELECT rowid FROM t1 WHERE rowid+0 IN (SELECT rowid FROM t1); }
1.67 +} {0 1 2 3}
1.68 +do_test in3-1.5 {
1.69 + exec_neph { SELECT a FROM t1 WHERE a+0 IN (SELECT a FROM t1); }
1.70 +} {0 1 3 5}
1.71 +
1.72 +# Because none of the sub-select queries in the following statements
1.73 +# match the pattern ("SELECT <column> FROM <table>"), the following do
1.74 +# require a temp table.
1.75 +#
1.76 +do_test in3-1.6 {
1.77 + exec_neph { SELECT rowid FROM t1 WHERE rowid IN (SELECT rowid+0 FROM t1); }
1.78 +} {1 1 2 3}
1.79 +do_test in3-1.7 {
1.80 + exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a+0 FROM t1); }
1.81 +} {1 1 3 5}
1.82 +do_test in3-1.8 {
1.83 + exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a FROM t1 WHERE 1); }
1.84 +} {1 1 3 5}
1.85 +do_test in3-1.9 {
1.86 + exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a FROM t1 GROUP BY a); }
1.87 +} {1 1 3 5}
1.88 +
1.89 +# This should not use a temp-table. Even though the sub-select does
1.90 +# not exactly match the pattern "SELECT <column> FROM <table>", in
1.91 +# this case the ORDER BY is a no-op and can be ignored.
1.92 +do_test in3-1.10 {
1.93 + exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a FROM t1 ORDER BY a); }
1.94 +} {0 1 3 5}
1.95 +
1.96 +# These do use the temp-table. Adding the LIMIT clause means the
1.97 +# ORDER BY cannot be ignored.
1.98 +do_test in3-1.11 {
1.99 + exec_neph {SELECT a FROM t1 WHERE a IN (SELECT a FROM t1 ORDER BY a LIMIT 1)}
1.100 +} {1 1}
1.101 +do_test in3-1.12 {
1.102 + exec_neph {
1.103 + SELECT a FROM t1 WHERE a IN (SELECT a FROM t1 ORDER BY a LIMIT 1 OFFSET 1)
1.104 + }
1.105 +} {1 3}
1.106 +
1.107 +# Has to use a temp-table because of the compound sub-select.
1.108 +#
1.109 +ifcapable compound {
1.110 + do_test in3-1.13 {
1.111 + exec_neph {
1.112 + SELECT a FROM t1 WHERE a IN (
1.113 + SELECT a FROM t1 UNION ALL SELECT a FROM t1
1.114 + )
1.115 + }
1.116 + } {1 1 3 5}
1.117 +}
1.118 +
1.119 +# The first of these queries has to use the temp-table, because the
1.120 +# collation sequence used for the index on "t1.a" does not match the
1.121 +# collation sequence used by the "IN" comparison. The second does not
1.122 +# require a temp-table, because the collation sequences match.
1.123 +#
1.124 +do_test in3-1.14 {
1.125 + exec_neph { SELECT a FROM t1 WHERE a COLLATE nocase IN (SELECT a FROM t1) }
1.126 +} {1 1 3 5}
1.127 +do_test in3-1.15 {
1.128 + exec_neph { SELECT a FROM t1 WHERE a COLLATE binary IN (SELECT a FROM t1) }
1.129 +} {0 1 3 5}
1.130 +
1.131 +# Neither of these queries require a temp-table. The collation sequence
1.132 +# makes no difference when using a rowid.
1.133 +#
1.134 +do_test in3-1.16 {
1.135 + exec_neph {SELECT a FROM t1 WHERE a COLLATE nocase IN (SELECT rowid FROM t1)}
1.136 +} {0 1 3}
1.137 +do_test in3-1.17 {
1.138 + exec_neph {SELECT a FROM t1 WHERE a COLLATE binary IN (SELECT rowid FROM t1)}
1.139 +} {0 1 3}
1.140 +
1.141 +# The following tests - in3.2.* - test a bug that was difficult to track
1.142 +# down during development. They are not particularly well focused.
1.143 +#
1.144 +do_test in3-2.1 {
1.145 + execsql {
1.146 + DROP TABLE IF EXISTS t1;
1.147 + CREATE TABLE t1(w int, x int, y int);
1.148 + CREATE TABLE t2(p int, q int, r int, s int);
1.149 + }
1.150 + for {set i 1} {$i<=100} {incr i} {
1.151 + set w $i
1.152 + set x [expr {int(log($i)/log(2))}]
1.153 + set y [expr {$i*$i + 2*$i + 1}]
1.154 + execsql "INSERT INTO t1 VALUES($w,$x,$y)"
1.155 + }
1.156 + set maxy [execsql {select max(y) from t1}]
1.157 + db eval { INSERT INTO t2 SELECT 101-w, x, $maxy+1-y, y FROM t1 }
1.158 +} {}
1.159 +do_test in3-2.2 {
1.160 + execsql {
1.161 + SELECT rowid
1.162 + FROM t1
1.163 + WHERE rowid IN (SELECT rowid FROM t1 WHERE rowid IN (1, 2));
1.164 + }
1.165 +} {1 2}
1.166 +do_test in3-2.3 {
1.167 + execsql {
1.168 + select rowid from t1 where rowid IN (-1,2,4)
1.169 + }
1.170 +} {2 4}
1.171 +do_test in3-2.4 {
1.172 + execsql {
1.173 + SELECT rowid FROM t1 WHERE rowid IN
1.174 + (select rowid from t1 where rowid IN (-1,2,4))
1.175 + }
1.176 +} {2 4}
1.177 +
1.178 +#-------------------------------------------------------------------------
1.179 +# This next block of tests - in3-3.* - verify that column affinity is
1.180 +# correctly handled in cases where an index might be used to optimise
1.181 +# an IN (SELECT) expression.
1.182 +#
1.183 +do_test in3-3.1 {
1.184 + catch {execsql {
1.185 + DROP TABLE t1;
1.186 + DROP TABLE t2;
1.187 + }}
1.188 +
1.189 + execsql {
1.190 +
1.191 + CREATE TABLE t1(a BLOB, b NUMBER ,c TEXT);
1.192 + CREATE UNIQUE INDEX t1_i1 ON t1(a); /* no affinity */
1.193 + CREATE UNIQUE INDEX t1_i2 ON t1(b); /* numeric affinity */
1.194 + CREATE UNIQUE INDEX t1_i3 ON t1(c); /* text affinity */
1.195 +
1.196 + CREATE TABLE t2(x BLOB, y NUMBER, z TEXT);
1.197 + CREATE UNIQUE INDEX t2_i1 ON t2(x); /* no affinity */
1.198 + CREATE UNIQUE INDEX t2_i2 ON t2(y); /* numeric affinity */
1.199 + CREATE UNIQUE INDEX t2_i3 ON t2(z); /* text affinity */
1.200 +
1.201 + INSERT INTO t1 VALUES(1, 1, 1);
1.202 + INSERT INTO t2 VALUES('1', '1', '1');
1.203 + }
1.204 +} {}
1.205 +
1.206 +do_test in3-3.2 {
1.207 + # No affinity is applied before comparing "x" and "a". Therefore
1.208 + # the index can be used (the comparison is false, text!=number).
1.209 + exec_neph { SELECT x IN (SELECT a FROM t1) FROM t2 }
1.210 +} {0 0}
1.211 +do_test in3-3.3 {
1.212 + # Logically, numeric affinity is applied to both sides before
1.213 + # the comparison. Therefore it is possible to use index t1_i2.
1.214 + exec_neph { SELECT x IN (SELECT b FROM t1) FROM t2 }
1.215 +} {0 1}
1.216 +do_test in3-3.4 {
1.217 + # No affinity is applied before the comparison takes place. Making
1.218 + # it possible to use index t1_i3.
1.219 + exec_neph { SELECT x IN (SELECT c FROM t1) FROM t2 }
1.220 +} {0 1}
1.221 +
1.222 +do_test in3-3.5 {
1.223 + # Numeric affinity should be applied to each side before the comparison
1.224 + # takes place. Therefore we cannot use index t1_i1, which has no affinity.
1.225 + exec_neph { SELECT y IN (SELECT a FROM t1) FROM t2 }
1.226 +} {1 1}
1.227 +do_test in3-3.6 {
1.228 + # Numeric affinity is applied to both sides before
1.229 + # the comparison. Therefore it is possible to use index t1_i2.
1.230 + exec_neph { SELECT y IN (SELECT b FROM t1) FROM t2 }
1.231 +} {0 1}
1.232 +do_test in3-3.7 {
1.233 + # Numeric affinity is applied before the comparison takes place.
1.234 + # Making it impossible to use index t1_i3.
1.235 + exec_neph { SELECT y IN (SELECT c FROM t1) FROM t2 }
1.236 +} {1 1}
1.237 +
1.238 +#---------------------------------------------------------------------
1.239 +#
1.240 +# Test using a multi-column index.
1.241 +#
1.242 +do_test in3-4.1 {
1.243 + execsql {
1.244 + CREATE TABLE t3(a, b, c);
1.245 + CREATE UNIQUE INDEX t3_i ON t3(b, a);
1.246 + }
1.247 +
1.248 + execsql {
1.249 + INSERT INTO t3 VALUES(1, 'numeric', 2);
1.250 + INSERT INTO t3 VALUES(2, 'text', 2);
1.251 + INSERT INTO t3 VALUES(3, 'real', 2);
1.252 + INSERT INTO t3 VALUES(4, 'none', 2);
1.253 + }
1.254 +} {}
1.255 +do_test in3-4.2 {
1.256 + exec_neph { SELECT 'text' IN (SELECT b FROM t3) }
1.257 +} {0 1}
1.258 +do_test in3-4.3 {
1.259 + exec_neph { SELECT 'TEXT' COLLATE nocase IN (SELECT b FROM t3) }
1.260 +} {1 1}
1.261 +do_test in3-4.4 {
1.262 + # A temp table must be used because t3_i.b is not guaranteed to be unique.
1.263 + exec_neph { SELECT b FROM t3 WHERE b IN (SELECT b FROM t3) }
1.264 +} {1 none numeric real text}
1.265 +do_test in3-4.5 {
1.266 + execsql { CREATE UNIQUE INDEX t3_i2 ON t3(b) }
1.267 + exec_neph { SELECT b FROM t3 WHERE b IN (SELECT b FROM t3) }
1.268 +} {0 none numeric real text}
1.269 +do_test in3-4.6 {
1.270 + execsql { DROP INDEX t3_i2 }
1.271 +} {}
1.272 +
1.273 +# The following two test cases verify that ticket #2991 has been fixed.
1.274 +#
1.275 +do_test in3-5.1 {
1.276 + execsql {
1.277 + CREATE TABLE Folders(
1.278 + folderid INTEGER PRIMARY KEY,
1.279 + parentid INTEGER,
1.280 + rootid INTEGER,
1.281 + path VARCHAR(255)
1.282 + );
1.283 + }
1.284 +} {}
1.285 +do_test in3-5.2 {
1.286 + catchsql {
1.287 + DELETE FROM Folders WHERE folderid IN
1.288 + (SELECT folderid FROM Folder WHERE path LIKE 'C:\MP3\Albums\' || '%');
1.289 + }
1.290 +} {1 {no such table: Folder}}
1.291 +
1.292 +finish_test