Add //third_party/sqlite to dirs_to_snapshot, remove net_sql.patch

third_party/sqlite/sqlite-src-3080704/test/tkt2820.test

Index: third_party/sqlite/sqlite-src-3080704/test/tkt2820.test
diff --git a/third_party/sqlite/sqlite-src-3080704/test/tkt2820.test b/third_party/sqlite/sqlite-src-3080704/test/tkt2820.test
new file mode 100644
index 0000000000000000000000000000000000000000..11c4cd3a0f04b09a3b4c451a2b92009468f75944
--- /dev/null
+++ b/third_party/sqlite/sqlite-src-3080704/test/tkt2820.test
@@ -0,0 +1,94 @@
+# 2007 Dec 4
+#
+# 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 is to test that ticket #2820 has been fixed.
+# Ticket #2820 observes that a DROP TABLE statement that
+# occurs while a query is in process will fail with a
+# "database is locked" error, but the entry in the sqlite_master
+# table will still be removed.  This is incorrect.  The
+# entry in the sqlite_master table should persist when 
+# the DROP fails due to an error.
+#
+# $Id: tkt2820.test,v 1.1 2007/12/04 16:54:53 drh Exp $
+#
+
+set testdir [file dirname $argv0]
+source $testdir/tester.tcl
+
+proc test_schema_change {testid init ddl res} {
+  db close
+  forcedelete test.db test.db-journal
+  sqlite3 db test.db
+  execsql $init
+  do_test tkt2820-$testid.1 {
+    set STMT [sqlite3_prepare db {SELECT * FROM sqlite_master} -1 DUMMY]
+    sqlite3_step $STMT
+  } {SQLITE_ROW}
+#if {$testid==3} {execsql {PRAGMA vdbe_trace=ON}}
+  do_test tkt2820-$testid.2 "catchsql [list $ddl]" \
+       {1 {database table is locked}}
+  do_test tkt2820-$testid.3 {
+    sqlite3_finalize $STMT
+    execsql {SELECT name FROM sqlite_master ORDER BY 1}
+  } $res
+  integrity_check tkt2820-$testid.4
+  db close
+  sqlite3 db test.db
+  integrity_check tkt2820-$testid.5
+}
+
+test_schema_change 1 {
+  CREATE TABLE t1(a);
+} {
+  DROP TABLE t1
+} {t1}
+test_schema_change 2 {
+  CREATE TABLE t1(a);
+  CREATE TABLE t2(b);
+} {
+  DROP TABLE t2
+} {t1 t2}
+test_schema_change 3 {
+  CREATE TABLE t1(a);
+  CREATE INDEX i1 ON t1(a);
+} {
+  DROP INDEX i1
+} {i1 t1}
+
+# We further observe that prior to the fix associated with ticket #2820,
+# no statement journal would be created on an SQL statement that was run
+# while a second statement was active, as long as we are in autocommit
+# mode.  This is incorrect.
+#
+do_test tkt2820-4.1 {
+  db close
+  forcedelete test.db test.db-journal
+  sqlite3 db test.db
+  db eval {
+    CREATE TABLE t1(a INTEGER PRIMARY KEY);
+    INSERT INTO t1 VALUES(1);
+    INSERT INTO t1 VALUES(2);
+  }
+
+  # The INSERT statement within the loop should fail on a
+  # constraint violation on the second inserted row.  This
+  # should cause the entire INSERT to rollback using a statement
+  # journal.
+  #
+  db eval {SELECT name FROM sqlite_master} {
+    catch {db eval {
+      INSERT INTO t1 SELECT a+1 FROM t1 ORDER BY a DESC
+    }}
+  }
+  db eval {SELECT a FROM t1 ORDER BY a}
+} {1 2}
+
+finish_test