Applying fts2.patch to fts3.

third_party/sqlite/README.chromium

 Name: SQLite
 URL: http://sqlite.org/
 
 Instructions for importing a new release of SQLite from sqlite.org.
 
 Note: our current base version is 3.6.18.
 
 First, you need to be on Linux.
 
 # Determine the versions of the release you want and the release we currently
@@ skipping 39 matching lines @@
 For reference, all of our local patches are also kept as .patch files in the
 sqlite directory. Here is a list of the patches, in the order they should be
 applied to a vanilla SQLite (of the version we currently have) to get, in
 principle, exactly what is checked in:
 
 misc.patch
 preload-cache.patch
 safe-tolower.patch
 sqlite-poison.patch
 fts2.patch
+fts3.patch
 icu-regexp.patch
 attach-integer.patch
 
 So, e.g. you could do this to apply all our patches to vanilla SQLite:
 
 cd sqlite-$LATEST
 patch -p0 < ../sqlite/misc.patch
 patch -p0 < ../sqlite/preload-cache.patch
 patch -p0 < ../sqlite/safe-tolower.patch
 patch -p0 < ../sqlite/sqlite-poison.patch
 patch -p0 < ../sqlite/fts2.patch
+patch -p0 < ../sqlite/fts3.patch
 patch -p0 < ../sqlite/icu-regexp.patch
 patch -p0 < ../sqlite/attach-integer.patch
 
 This will only be the case if all changes we make also update the corresponding
 patch files. Therefore please remember to do that whenever you make a change!
 
 Descriptions of the changes we've made can be found at the bottom of this file.
 
 --------------------------------------------
 
@@ skipping 14 matching lines @@
 # However, the current situation on my corp Linux Ubuntu 8.04 machine, with
 # test run on a locally mounted directory, is the failure of:
 # "rollback-2.3", "tkt3457-1.4"
 # I do not know why, but it is not related to our fts2.c changes -- I backed
 # them out to check.
 
 Chris Evans <cevans@google.com>, Oct 1, 2009
 
 --------------------------------------------
 
-As of Dec 16, 2009, these are our changes from sqlite_vendor:
+As of May 07, 2010, these are our changes from sqlite_vendor:
 
  - A fix for a crash passing an integer expression to ATTACH / DETACH. See
  attach-integer.patch
  - A fix for a crash mis-calling the REGEXP() function of the ICU extension.
  See icu-regexp.patch
  - A large number of fts2 robustness fixes against corrupt data in its metadata
    tables.
  - fts2.c disables fts2_tokenizer().
+ - fts3.c disables fts3_tokenizer().
  - sqlite3Poison() in src/btree.c.
  - Tweak to SQLITE_EXTENSION_INIT* in sqlite3ext.h.
    - That implied a change in src/test_autoext.c for testing.
  - Added fts.test and fts1.test in tests, modified quick.test.
  - src/os_symbian.cc.
  - Modifications to Makefile.linux-gcc and main.mk for compiling
    SQLite tests.
  - Compile warning (cast to void* for sqlite3_free) fixed in func.c.
  - Avoid using tolower() in fts code which causes problem in some locales, see:
    safe-tolower.patch
@@ skipping 10 matching lines @@
    fts2_tokenizer.c and icu.c.  Without this #define, the calls in
    fts2_tokenizer.c try to go through some pointer to the sqlite API instead
    of calling the functions directly (to work as a loadable module), but then
    crash (because the other files never initialize that loadable module
    support).  As a hack I #defined it in these files, but it'd be nice to
    figure out what really ought to happen here (perhaps this file is new and
    hasn't been tested to verify it works right).  Update: Seems this is an
    issue we get because we're using fts2 instead of fts3.
  - shell_icu_win.c and shell_icu_linux.c are Chrome-specific files used to load
    our ICU data.  shell.c has been modifed to call into these files.
- - fts2_icu.c has a critical bug. U8_NEXT is used over a UTF-16 string. It's
-   rep$ by U16_NEXT (jungshik)
+ - fts2_icu.c and fts3_icu.c have a critical bug. U8_NEXT is used over
+   a UTF-16 string. It's rep$ by U16_NEXT (jungshik)
  - Added a new function sqlite3Preload we use to prime the database cache. It
    allows much faster performance by reading the file in one contiguous
    operation rather than bringing it in organically, which involves a lot of
    seeking. This change also required sqlite3PcacheGetCachesize to be compiled
    even outside SQLITE_TEST.
  - Added a new function chromium_sqlite3_initialize_win_sqlite3_file()
    at the end of os_win.c. It allows the Windows-specific Chromium VFS
    to reuse most of the win32 SQLite VFS.
  - Added a new function
    chromium_sqlite3_initialize_unix_sqlite3_file() and made
    fillInUnixFile() non-static in os_unix.c. It allows the
    Linux-specific Chromium VFS to reuse most of the unix SQLite VFS.
  - Exposed three functions that deal with unused file descriptors in
    os_unix.c, to allow Chromium's Posix VFS implementation in
    WebKit/WebCore/platform/sql/chromium/SQLiteFileSystemChromiumPosix.cpp
    to correctly implement the "unused file descriptors" logic in the
    xDlOpen() method. The new functions are
    chromium_sqlite3_get_reusable_file_handle(),
    chromium_sqlite3_update_reusable_file_handle() and
    chromium_sqlite3_destroy_reusable_file_handle(). Also, added the
    chromium_sqlite3_fill_in_unix_sqlite3_file() function that calls
    fillInUnixFile(), which will be made static again as soon as a
    WebKit patch using the new function lands.