Index: third_party/sqlite/sqlite-src-3080704/test/in3.test |
diff --git a/third_party/sqlite/sqlite-src-3080704/test/in3.test b/third_party/sqlite/sqlite-src-3080704/test/in3.test |
deleted file mode 100644 |
index 012c9b44526005849488bd363a65b122e2c6e0f2..0000000000000000000000000000000000000000 |
--- a/third_party/sqlite/sqlite-src-3080704/test/in3.test |
+++ /dev/null |
@@ -1,289 +0,0 @@ |
-# 2007 November 29 |
-# |
-# The author disclaims copyright to this source code. In place of |
-# a legal notice, here is a blessing: |
-# |
-# May you do good and not evil. |
-# May you find forgiveness for yourself and forgive others. |
-# May you share freely, never taking more than you give. |
-# |
-#*********************************************************************** |
-# This file tests the optimisations made in November 2007 of expressions |
-# of the following form: |
-# |
-# <value> IN (SELECT <column> FROM <table>) |
-# |
-# $Id: in3.test,v 1.5 2008/08/04 03:51:24 danielk1977 Exp $ |
- |
-set testdir [file dirname $argv0] |
-source $testdir/tester.tcl |
- |
-ifcapable !subquery { |
- finish_test |
- return |
-} |
- |
-# Return the number of OpenEphemeral instructions used in the |
-# implementation of the sql statement passed as a an argument. |
-# |
-proc nEphemeral {sql} { |
- set nEph 0 |
- foreach op [execsql "EXPLAIN $sql"] { |
- if {$op eq "OpenEphemeral"} {incr nEph} |
- } |
- set nEph |
-} |
- |
-# This proc works the same way as execsql, except that the number |
-# of OpenEphemeral instructions used in the implementation of the |
-# statement is inserted into the start of the returned list. |
-# |
-proc exec_neph {sql} { |
- return [concat [nEphemeral $sql] [execsql $sql]] |
-} |
- |
-do_test in3-1.1 { |
- execsql { |
- CREATE TABLE t1(a PRIMARY KEY, b); |
- INSERT INTO t1 VALUES(1, 2); |
- INSERT INTO t1 VALUES(3, 4); |
- INSERT INTO t1 VALUES(5, 6); |
- } |
-} {} |
- |
-# All of these queries should avoid using a temp-table: |
-# |
-do_test in3-1.2 { |
- exec_neph { SELECT rowid FROM t1 WHERE rowid IN (SELECT rowid FROM t1); } |
-} {0 1 2 3} |
-do_test in3-1.3 { |
- exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a FROM t1); } |
-} {0 1 3 5} |
-do_test in3-1.4 { |
- exec_neph { SELECT rowid FROM t1 WHERE rowid+0 IN (SELECT rowid FROM t1); } |
-} {0 1 2 3} |
-do_test in3-1.5 { |
- exec_neph { SELECT a FROM t1 WHERE a+0 IN (SELECT a FROM t1); } |
-} {0 1 3 5} |
- |
-# Because none of the sub-select queries in the following statements |
-# match the pattern ("SELECT <column> FROM <table>"), the following do |
-# require a temp table. |
-# |
-do_test in3-1.6 { |
- exec_neph { SELECT rowid FROM t1 WHERE rowid IN (SELECT rowid+0 FROM t1); } |
-} {1 1 2 3} |
-do_test in3-1.7 { |
- exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a+0 FROM t1); } |
-} {1 1 3 5} |
-do_test in3-1.8 { |
- exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a FROM t1 WHERE 1); } |
-} {1 1 3 5} |
-do_test in3-1.9 { |
- exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a FROM t1 GROUP BY a); } |
-} {1 1 3 5} |
- |
-# This should not use a temp-table. Even though the sub-select does |
-# not exactly match the pattern "SELECT <column> FROM <table>", in |
-# this case the ORDER BY is a no-op and can be ignored. |
-do_test in3-1.10 { |
- exec_neph { SELECT a FROM t1 WHERE a IN (SELECT a FROM t1 ORDER BY a); } |
-} {0 1 3 5} |
- |
-# These do use the temp-table. Adding the LIMIT clause means the |
-# ORDER BY cannot be ignored. |
-do_test in3-1.11 { |
- exec_neph {SELECT a FROM t1 WHERE a IN (SELECT a FROM t1 ORDER BY a LIMIT 1)} |
-} {1 1} |
-do_test in3-1.12 { |
- exec_neph { |
- SELECT a FROM t1 WHERE a IN (SELECT a FROM t1 ORDER BY a LIMIT 1 OFFSET 1) |
- } |
-} {1 3} |
- |
-# Has to use a temp-table because of the compound sub-select. |
-# |
-ifcapable compound { |
- do_test in3-1.13 { |
- exec_neph { |
- SELECT a FROM t1 WHERE a IN ( |
- SELECT a FROM t1 UNION ALL SELECT a FROM t1 |
- ) |
- } |
- } {1 1 3 5} |
-} |
- |
-# The first of these queries has to use the temp-table, because the |
-# collation sequence used for the index on "t1.a" does not match the |
-# collation sequence used by the "IN" comparison. The second does not |
-# require a temp-table, because the collation sequences match. |
-# |
-do_test in3-1.14 { |
- exec_neph { SELECT a FROM t1 WHERE a COLLATE nocase IN (SELECT a FROM t1) } |
-} {1 1 3 5} |
-do_test in3-1.15 { |
- exec_neph { SELECT a FROM t1 WHERE a COLLATE binary IN (SELECT a FROM t1) } |
-} {0 1 3 5} |
- |
-# Neither of these queries require a temp-table. The collation sequence |
-# makes no difference when using a rowid. |
-# |
-do_test in3-1.16 { |
- exec_neph {SELECT a FROM t1 WHERE a COLLATE nocase IN (SELECT rowid FROM t1)} |
-} {0 1 3} |
-do_test in3-1.17 { |
- exec_neph {SELECT a FROM t1 WHERE a COLLATE binary IN (SELECT rowid FROM t1)} |
-} {0 1 3} |
- |
-# The following tests - in3.2.* - test a bug that was difficult to track |
-# down during development. They are not particularly well focused. |
-# |
-do_test in3-2.1 { |
- execsql { |
- DROP TABLE IF EXISTS t1; |
- CREATE TABLE t1(w int, x int, y int); |
- CREATE TABLE t2(p int, q int, r int, s int); |
- } |
- for {set i 1} {$i<=100} {incr i} { |
- set w $i |
- set x [expr {int(log($i)/log(2))}] |
- set y [expr {$i*$i + 2*$i + 1}] |
- execsql "INSERT INTO t1 VALUES($w,$x,$y)" |
- } |
- set maxy [execsql {select max(y) from t1}] |
- db eval { INSERT INTO t2 SELECT 101-w, x, $maxy+1-y, y FROM t1 } |
-} {} |
-do_test in3-2.2 { |
- execsql { |
- SELECT rowid |
- FROM t1 |
- WHERE rowid IN (SELECT rowid FROM t1 WHERE rowid IN (1, 2)); |
- } |
-} {1 2} |
-do_test in3-2.3 { |
- execsql { |
- select rowid from t1 where rowid IN (-1,2,4) |
- } |
-} {2 4} |
-do_test in3-2.4 { |
- execsql { |
- SELECT rowid FROM t1 WHERE rowid IN |
- (select rowid from t1 where rowid IN (-1,2,4)) |
- } |
-} {2 4} |
- |
-#------------------------------------------------------------------------- |
-# This next block of tests - in3-3.* - verify that column affinity is |
-# correctly handled in cases where an index might be used to optimise |
-# an IN (SELECT) expression. |
-# |
-do_test in3-3.1 { |
- catch {execsql { |
- DROP TABLE t1; |
- DROP TABLE t2; |
- }} |
- |
- execsql { |
- |
- CREATE TABLE t1(a BLOB, b NUMBER ,c TEXT); |
- CREATE UNIQUE INDEX t1_i1 ON t1(a); /* no affinity */ |
- CREATE UNIQUE INDEX t1_i2 ON t1(b); /* numeric affinity */ |
- CREATE UNIQUE INDEX t1_i3 ON t1(c); /* text affinity */ |
- |
- CREATE TABLE t2(x BLOB, y NUMBER, z TEXT); |
- CREATE UNIQUE INDEX t2_i1 ON t2(x); /* no affinity */ |
- CREATE UNIQUE INDEX t2_i2 ON t2(y); /* numeric affinity */ |
- CREATE UNIQUE INDEX t2_i3 ON t2(z); /* text affinity */ |
- |
- INSERT INTO t1 VALUES(1, 1, 1); |
- INSERT INTO t2 VALUES('1', '1', '1'); |
- } |
-} {} |
- |
-do_test in3-3.2 { |
- # No affinity is applied before comparing "x" and "a". Therefore |
- # the index can be used (the comparison is false, text!=number). |
- exec_neph { SELECT x IN (SELECT a FROM t1) FROM t2 } |
-} {0 0} |
-do_test in3-3.3 { |
- # Logically, numeric affinity is applied to both sides before |
- # the comparison. Therefore it is possible to use index t1_i2. |
- exec_neph { SELECT x IN (SELECT b FROM t1) FROM t2 } |
-} {0 1} |
-do_test in3-3.4 { |
- # No affinity is applied before the comparison takes place. Making |
- # it possible to use index t1_i3. |
- exec_neph { SELECT x IN (SELECT c FROM t1) FROM t2 } |
-} {0 1} |
- |
-do_test in3-3.5 { |
- # Numeric affinity should be applied to each side before the comparison |
- # takes place. Therefore we cannot use index t1_i1, which has no affinity. |
- exec_neph { SELECT y IN (SELECT a FROM t1) FROM t2 } |
-} {1 1} |
-do_test in3-3.6 { |
- # Numeric affinity is applied to both sides before |
- # the comparison. Therefore it is possible to use index t1_i2. |
- exec_neph { SELECT y IN (SELECT b FROM t1) FROM t2 } |
-} {0 1} |
-do_test in3-3.7 { |
- # Numeric affinity is applied before the comparison takes place. |
- # Making it impossible to use index t1_i3. |
- exec_neph { SELECT y IN (SELECT c FROM t1) FROM t2 } |
-} {1 1} |
- |
-#--------------------------------------------------------------------- |
-# |
-# Test using a multi-column index. |
-# |
-do_test in3-4.1 { |
- execsql { |
- CREATE TABLE t3(a, b, c); |
- CREATE UNIQUE INDEX t3_i ON t3(b, a); |
- } |
- |
- execsql { |
- INSERT INTO t3 VALUES(1, 'numeric', 2); |
- INSERT INTO t3 VALUES(2, 'text', 2); |
- INSERT INTO t3 VALUES(3, 'real', 2); |
- INSERT INTO t3 VALUES(4, 'none', 2); |
- } |
-} {} |
-do_test in3-4.2 { |
- exec_neph { SELECT 'text' IN (SELECT b FROM t3) } |
-} {0 1} |
-do_test in3-4.3 { |
- exec_neph { SELECT 'TEXT' COLLATE nocase IN (SELECT b FROM t3) } |
-} {1 1} |
-do_test in3-4.4 { |
- # A temp table must be used because t3_i.b is not guaranteed to be unique. |
- exec_neph { SELECT b FROM t3 WHERE b IN (SELECT b FROM t3) } |
-} {1 none numeric real text} |
-do_test in3-4.5 { |
- execsql { CREATE UNIQUE INDEX t3_i2 ON t3(b) } |
- exec_neph { SELECT b FROM t3 WHERE b IN (SELECT b FROM t3) } |
-} {0 none numeric real text} |
-do_test in3-4.6 { |
- execsql { DROP INDEX t3_i2 } |
-} {} |
- |
-# The following two test cases verify that ticket #2991 has been fixed. |
-# |
-do_test in3-5.1 { |
- execsql { |
- CREATE TABLE Folders( |
- folderid INTEGER PRIMARY KEY, |
- parentid INTEGER, |
- rootid INTEGER, |
- path VARCHAR(255) |
- ); |
- } |
-} {} |
-do_test in3-5.2 { |
- catchsql { |
- DELETE FROM Folders WHERE folderid IN |
- (SELECT folderid FROM Folder WHERE path LIKE 'C:\MP3\Albums\' || '%'); |
- } |
-} {1 {no such table: Folder}} |
- |
-finish_test |