Fix issue 15261: Crash in history::TextDatabase::GetTextMatches...

third_party/sqlite/README.chromium

 Instructions for importing a new release of sqlite from sqlite.org.
 
 First, you need to be on Linux.
 
 Find the release you want at:
   http://www.sqlite.org/cvstrac/timeline
 
 Search for "Milestone", and find the appropriate release.  Click
 through, and snag the "Date" for use in DATE line below.
 Unfortunately, the actual displayed date string on that page will not
@@ skipping 50 matching lines @@
 make -f ../Makefile.linux-gcc testfixture
 make -f ../Makefile.linux-gcc test > /tmp/test.log
 egrep -v 'Ok$' /tmp/test.log
 # When run on a locally-mounted disk, my output ends with:
 # 0 errors out of 57887 tests
 
 Scott Hess <shess@google.com>, December 11, 2007
 
 --------------------------------------------
 
-As of July 20, 2009, these are our changes from sqlite_vendor:
+As of Sep 2, 2009, these are our changes from sqlite_vendor:
 
  - fts2.c disables fts2_tokenizer().
  - sqlite3Poison() in src/btree.c.
  - BEGIN defaults to BEGIN IMMEDIATE in parse.y.
  - 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 fixed in func.c (check if this is still needed)
  - Fixed a typo bug in fts2_icu.c: "strlen(nInput)" (filed upstream as
    http://www.sqlite.org/cvstrac/tktview?tn=3543)
+ - Avoid using tolower() in fts code which causes problem in some locales, see:
+   safe-tolower.patch
+   http://crbug.com/15261
+   http://www.sqlite.org/src/tktview/991789d9f3136a0460dc83a33e815c1aa9757c26
 
 Changes from Chrome:
  - I marked all changes I made with "evanm", so you can find them with
    "grep evanm *".
  - Most files include sqlite3ext.h with SQLITE_CORE #defined, but two don't:
    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)
  - 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.
  - 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 initUnixFile() and made fillInUnixFile()
    non-static in os_unix.c. It allows the Linux-specific Chromium VFS
    to reuse most of the unix SQLite VFS.