CVS import: src/external/public-domain/sqlite/dist

["Christos Zoulas" <christos%netbsd.org@localhost>]

Module Name:    src
Committed By:   christos
Date:           Sun Feb 16 18:04:40 UTC 2014

Update of /cvsroot/src/external/public-domain/sqlite/dist
In directory ivanova.netbsd.org:/tmp/cvs-serv29002

Log Message:
from www.sqlite.org: Changes since 3.6.9:

2014-02-11 - Release 3.8.3.1

SQLite version 3.8.3.1 fixes a bug present in versions 3.8.1, 3.8.2 and 3.8.3 
that can cause queries to omit valid out rows. Upgrading from those versions is 
recommended.

The problem only comes up if SQLite is compiled with either the 
SQLITE_ENABLE_STAT3 or SQLITE_ENABLE_STAT4 compile-time options. In that case, 
if a query has a WHERE clause that contains expressions like this:

WHERE (expr1 OR expr2 OR ... OR exprN) AND column IS NOT NULL
Where all of expr1 through exprN are suitable for use by indexes, then during 
query planning SQLite might mistakenly converted the "column IS NOT NULL" term 
into "column>NULL". But the latter term is never true, and so the query would 
return no rows.
The trouble ticket for this bug is [4c86b126f2]. It is recommended that all 
users upgrade to avoid this problem.

2014-02-03 - Release 3.8.3

SQLite version 3.8.3 is a regularly scheduled maintenance release. Upgrading 
from the previous release is optional.

The most visible change in version 3.8.3 is the addition of support for common 
table expressions. It is now possible to write a single SELECT statement that 
will query a tree or graph, using either a depth-first or a breadth-first 
search. A single SQLite query will even solve Sudoku puzzles or compute the 
Mandelbrot set. As part of this change, SQLite now accepts a VALUES clause 
anyplace that a SELECT statement is valid.

This release also includes many small performance enhancements which should 
give a small speed boost to legacy applications. And there are other minor 
enhancements such as the addition of the printf() SQL function. See the change 
log for details.

2013-12-06 - Release 3.8.2

SQLite version 3.8.2 is a regularly scheduled maintenance release. Upgrading 
from the previous release is optional.

Version 3.8.2 adds support for WITHOUT ROWID tables. This is a significant 
extension to SQLite. Database files that contain WITHOUT ROWID tables are not 
readable or writable by prior versions of SQLite, however databases that do not 
use WITHOUT ROWID tables are fully backwards and forwards compatible.

The 3.8.2 release contains a potentially incompatible change. In all prior 
versions of SQLite, a cast from a very large positive floating point number 
into an integer resulted in the most negative integer. In other words, 
CAST(+99.9e99 to INT) would yield -9223372036854775808. This behavior came 
about because it is what x86/x64 hardware does for the equivalent cast in the C 
language. But the behavior is bizarre. And so it has been changed effective 
with this release so that a cast from a floating point number into an integer 
returns the integer between the floating point value and zero that is closest 
to the floating point value. Hence, CAST(+99.9e99 to INT) now returns 
+9223372036854775807. Since routines like sqlite3_column_int64() do an implicit 
cast if the value being accessed is really a floating point number, they are 
also affected by this change.

Besides the two changes mentioned above, the 3.8.2 release also includes a 
number of performance enhancements. The skip-scan optimization is now available 
for databases that have been processed by ANALYZE. Constant SQL functions are 
now factored out of inner loops, which can result in a significant speedup for 
queries that contain WHERE clause terms like "date>datetime('now','-2 days')". 
And various high-runner internal routines have been refactored for reduced CPU 
load.

2013-10-17 - Release 3.8.1

SQLite version 3.8.1 is a regularly scheduled maintenance release. Upgrading 
from the previous release is optional, though you should upgrade if you are 
using partial indices as there was a bug related to partial indices in the 
previous release that could result in an incorrect answer for count(*) queries.

The next generation query planner that was premiered in the previous release 
continues to work well. The new query planner has been tweaked slightly in the 
current release to help it make better decisions in some cases, but is largely 
unchanged. Two new SQL functions, likelihood() and unlikely(), have been added 
to allow developers to give hints to the query planner without forcing the 
query planner into a particular decision.

Version 3.8.1 is the first SQLite release to take into account the estimated 
size of table and index rows when choosing a query plan. Row size estimates are 
based on the declared datatypes of columns. For example, a column of type 
VARCHAR(1000) is assumed to use much more space than a column of type INT. The 
datatype-based row size estimate can be overridden by appending a term of the 
form "sz=NNN" (where NNN is the average row size in bytes) to the end of the 
sqlite_stat1.stat record for a table or index. Currently, row sizes are only 
used to help the query planner choose between a table or one of its indices 
when doing a table scan or a count(*) operation, though future releases are 
likely to use the estimated row size in other contexts as well. The new PRAGMA 
stats statement can be used to view row size estimates.

Version 3.8.1 adds the SQLITE_ENABLE_STAT4 compile-time option. STAT4 is very 
similar to STAT3 in that it uses samples from indices to try to guess how many 
rows of the index will be satisfy by WHERE clause constraints. The difference 
is that STAT4 samples all columns of the index whereas the older STAT3 only 
sampled the left-most column. Users of STAT3 are encouraged to upgrade to 
STAT4. Application developers should use STAT3 and STAT4 with caution since 
both options, by design, violate the query planner stability guarantee, making 
it more difficult to ensure uniform performance is widely-deployed and 
mass-produced embedded applications.

2013-09-03 - Release 3.8.0.2

SQLite version 3.8.0.2 contains a one-line fix to a bug in the new optimization 
that tries to omit unused LEFT JOINs from a query.

2013-08-29 - Release 3.8.0.1

SQLite version 3.8.0.1 fixes some obscure bugs that were uncovered by users in 
the 3.8.0 release. Changes from 3.8.0 are minimal.

2013-08-26 - Release 3.8.0

Do not fear the zero!
SQLite version 3.8.0 might easily have been called "3.7.18" instead. However, 
this release features the cutover of the next generation query planner or NGQP, 
and there is a small chance of breaking legacy programs that rely on undefined 
behavior in previous SQLite releases, and so the minor version number was 
incremented for that reason. But the risks are low and there is a query planner 
checklist is available to application developers to aid in avoiding problems.

SQLite version 3.8.0 is actually one of the most heavily tested SQLite releases 
ever. Thousands and thousands of beta copies have be downloaded, and presumably 
tested, and there have been no problem reports.

In addition to the next generation query planner, the 3.8.0 release adds 
support for partial indices, as well as several other new features. See the 
change log for further detail.

2013-05-20 - Release 3.7.17

SQLite version 3.7.17 is a regularly schedule maintenance release. Visit the 
change log for a full explanation of the changes in this release.
There are many bug fixes in version 3.7.17. But this does not indicate that 
3.7.16 was a problematic release. All of the bugs in 3.7.17 are obscure and are 
unlikely to impact any particular application. And most of the bugs that are 
fixed in 3.7.17 predate 3.7.16 and have been in the code for years without ever 
before being noticed. Nevertheless, due to the large number of fixes, all users 
are encouraged to upgrade when possible.

2013-04-12 - Release 3.7.16.2

SQLite version 3.7.16.2 fixes a long-standing flaw in the Windows OS interface 
that can result in database corruption under a rare race condition. See 
http://www.sqlite.org/src/info/7ff3120e4f for a full description of the problem.
As far as we know, this bug has never been seen in the wild. The problem was 
discovered by the SQLite developers while writing stress tests for a separate 
component of SQLite. Those stress tests have not yet found any problems with 
the component they were intended to verify, but they did find the bug which is 
the subject of this patch release.

Other than updates to version numbers, the only difference between this release 
and 3.7.16.1 is a two-character change in a single identifier, which is 
contained in the windows-specific OS interface logic. There are no changes in 
this release (other than version numbers) for platforms other than Windows.

2013-03-29 - Release 3.7.16.1

SQLite version 3.7.16.1 is a bug fix release that fixes a few problems that 
were present in the previous releases.
The primary motivation for version 3.7.16.1 is to fix a bug in the query 
optimizer that was introduced as part of version 3.7.15. The query optimizer 
was being a little overzealous in optimizing out some ORDER BY clauses, which 
resulted in sorting being omitted on occasions where sorting is required to get 
the correct answer. See ticket a179fe7465 for details.

In addition to the ORDER BY fix, several other patches to fix obscure (and 
mostly harmless) bugs and to fix spelling errors in source code comments are 
also included in this release.

2013-03-18 - Release 3.7.16

SQLite version 3.7.16 is a regularly scheduled release of SQLite. This release 
contains several language enhancements and improvements to the query optimizer. 
A list of the major enhancements and optimizations can be see on the change log.
There was one important bug fix (see Ticket fc7bd6358f) that addresses an 
incorrect query result that could have occurred in a three-way join where the 
join constraints compared INTEGER columns to TEXT columns. This issue had been 
in the code for time out of mind and had never before been reported, so we 
surmise that it is very obscure. Nevertheless, all users are advised to upgrade 
to avoid any future problems associated with this issue.

2013-01-09 - Release 3.7.15.2

SQLite version 3.7.15.2 is a patch release that fixes a single bug that was 
introduced in version version 3.7.15. The fix is a 4-character edit to a single 
line of code. Other than this 4-character change and the update of the version 
number, nothing has changed from version 3.7.15.1.

2012-12-19 - Release 3.7.15.1

SQLite version 3.7.15.1 is a patch release that fixes a single bug that was 
introduced in version version 3.7.15. The fix involved changing two lines of 
code and adding a single assert(). This release also includes some new test 
cases to prevent a regression of the bug, and the version number is increased, 
of course. But otherwise, nothing has changed from version 3.7.15.
2012-12-12 - Release 3.7.15

SQLite version 3.7.15 is a regularly schedule release of SQLite. This release 
contains several improvements to the query planner and optimizer and one 
important bug fix. This is the first release to officially support Windows 8 
Phone.
The important bug fix is a problem that can lead to segfaults when using shared 
cache mode on a schema that contains a COLLATE operator within a CHECK 
constraint or within a view. Collating functions are associated with individual 
database connections. But a pointer to the collating function was also being 
cached within expressions. If an expression was part of the schema and 
contained a cached collating function, it would point to the collating function 
in the database connection that originally parsed the schema. If that database 
connection closed while other database connections using the same shared cache 
continued to operate, they other database connections would try to use the 
deallocated collating function in the database connection that closed. The fix 
in version 3.7.15 was to not cache collating function pointers in the 
expression structure but instead look them up each time a new statement is 
prepared.

This release also contains some important enhancements to the query planner 
which should (we hope) make some queries run faster. The enhancements include:

When doing a full-table scan, try to use an index instead of the original 
table, under the theory that indices contain less information and are thus 
smaller and hence require less disk I/O to scan.

Enhance the IN operator to allow it to make use of indices that have numeric 
affinity.

Do a better job of recognizing when an ORDER BY clause can be implemented using 
indices - especially in cases where the ORDER BY clause contains terms from two 
or more tables in a join.

2012-10-04 - Release 3.7.14.1

SQLite version 3.7.14.1 is a patch release. Changes from the baseline version 
3.7.14 are minimal and are restricted to fixing three bugs.
One of the fixed bugs is a long-standing issue with the TCL interface. Another 
is an external compiler bug that SQLite merely works around and that only comes 
up if you are using the VisualStudio-2012 compiler to generate WinRT 
applications on ARM with optimizations enabled. The third problem is an SQLite 
core bug, introduced in version 3.7.14, that can cause a segfault if a query 
contains a LEFT JOIN that contains an OR in the ON clause.

2012-09-03 - Release 3.7.14

SQLite version 3.7.14 is a regularly scheduled maintenance release of SQLite. 
The previous release continues to work well. Upgrading is optional.
Version 3.7.14 drops native support for OS/2. We are not aware of any active 
projects that were using SQLite on OS/2 and since the SQLite developers had no 
way of testing on OS/2 it seemed like it was time to simply remove the OS/2 
code from the SQLite tree. If there are OS/2 projects out there that still need 
SQLite support, they can continue to maintain their own private VFS which can 
be linked to SQLite at start-time using the sqlite3_vfs_register() interface.

The sqlite3_close_v2() interface has been added. The sqlite3_close_v2() 
interface differs from sqlite3_close() in that it is designed to work better 
for host language that use a garbage collector. With the older sqlite3_close() 
interface, the associated prepared statements and sqlite3_backup objects must 
be destroyed before the database connection. With the newer sqlite3_close_v2() 
interface, the objects can be destroyed in any order.

This release also includes performance improvements to the sort algorithm that 
is used to implement ORDER BY and CREATE INDEX. And the query planner has been 
enhanced to better use covering indices on queries that use OR terms in the 
WHERE clause.

2012-06-11 - Release 3.7.13

SQLite version 3.7.13 adds support for WinRT and metro style applications for 
Microsoft Windows 8. The 3.7.13 release is coming sooner than is usual after 
the previous release in order to get this new capability into the hands of 
developers. To use SQLite in a metro style application, compile with the 
-DSQLITE_OS_WINRT flag. Because of the increased application security and 
safety requirements of WinRT, all database filenames should be full pathnames. 
Note that SQLite is not capable of accessing databases outside the installation 
directory and application data directory. This restriction is another security 
and safety feature of WinRT. Apart from these restrictions, SQLite should work 
exactly the same on WinRT as it does on every other system.
Also in this release: when a database is opened using URI filenames and the 
mode=memory query parameter then the database is an in-memory database, just as 
if it had been named ":memory:". But, if shared cache mode is enabled, then all 
other database connections that specify the same URI filename will connect to 
the same in-memory database. This allows two or more database connections (in 
the same process) to share the same in-memory database.

This release also includes some corner-case performance optimizations that are 
obscure yet significant to an important subset of SQLite users. Getting these 
performance optimizations into circulation quickly is yet another reason for 
making this release so soon following the previous.

The next release of SQLite is scheduled to occur after the usual 2 or 3 month 
interval.

2012-05-22 - Patch Release 3.7.12.1

SQLite version 3.7.12.1 is a patch release for version 3.7.12 that fixes a bug 
that was introduced in version 3.7.12 and that can cause a segfault for certain 
obscure nested aggregate queries. There are very few changes in 3.7.12.1, and 
upgrading is only needed for applications that do nested aggregate queries.
2012-05-14 - Version 3.7.12

SQLite version 3.7.12 is a regularly scheduled maintenance release. This 
release contains several new optimizations and bug fixes and upgrading is 
recommended. See the change summary for details.
2012-03-20 - Version 3.7.11

SQLite version 3.7.11 is a regularly scheduled maintenance release which was 
rushed out early due to a bug in the query optimizer introduced in the previous 
release. The bug is obscure - it changes a LEFT JOIN into an INNER JOIN in some 
cases when there is a 3-way join and OR terms in the WHERE clause. But it was 
considered serious enough to rush out a fix. Apart from this one problem, 
SQLite version 3.7.10 has not given any trouble. Upgrading to version 3.7.11 
from versions 3.7.6.3, 3.7.7, 3.7.7.1, 3.7.8, or 3.7.9 is optional. Upgrading 
from other releases, including the previous release 3.7.10, is recommended.
Other enhancements found in this release are enumerated in the change log.

2012-01-16 - Version 3.7.10

SQLite version 3.7.10 is a regularly scheduled maintenance release. Upgrading 
from version 3.7.6.3, 3.7.7, 3.7.7.1, 3.7.8, or 3.7.9 is optional. Upgrading 
from other releases is recommended.
The SQLITE_CONFIG_PCACHE mechanism has been replaced with 
SQLITE_CONFIG_PCACHE2. If you do not know what this mechanism is (it is an 
extreme corner-case and is seldom used) then this change will not effect you in 
the least.

The default schema format number for new database files has changed from 1 to 
4. SQLite has been able to generate and read database files using schema format 
4 for six years. But up unto now, the default schema format has been 1 so that 
older versions of SQLite could read and write databases generated by newer 
versions of SQLite. But those older versions of SQLite have become so scarce 
now that it seems reasonable to make the new format the default.

SQLite is changing some of the assumptions it makes above the behavior of disk 
drives and flash memory devices during a sudden power loss. This change is 
completely transparent to applications. Read about the powersafe overwrite 
property for additional information.

Lots of new interfaces have been added in this release:

sqlite3_db_release_memory()
PRAGMA shrink_memory
sqlite3_db_filename()
sqlite3_stmt_busy()
sqlite3_uri_boolean()
sqlite3_uri_int64()
The PRAGMA cache_size statement has been enhanced. Formerly, you would use this 
statement to tell SQLite how many pages of the database files it should hold in 
its cache at once. The total memory requirement would depend on the database 
page size. Now, if you give PRAGMA cache_size a negative value -N, it will 
allocate roughly N kibibytes of memory to cache, divided up according to page 
size. This enhancement allows programs to more easily control their memory 
usage.

There have been several obscure bug fixes. One noteworthy bug, ticket 
ff5be73dee, could in theory result in a corrupt database file if a power loss 
occurred at just the wrong moment on an unusually cantankerous disk drive. But 
that is mostly a theoretical concern and is very unlikely to happen in 
practice. The bug was found during laboratory testing and has never been 
observed to occur in the wild.

2011-11-01 - Version 3.7.9

SQLite version 3.7.9 is a regularly scheduled maintenance release. Upgrading 
from version 3.7.6.3, 3.7.7, 3.7.7.1, and 3.7.8 is optional. Upgrading from 
other versions is recommended.
The SQLITE_ENABLE_STAT2 compile-time option is now a no-op. The enhanced 
query-planner functionality formerly available using SQLITE_ENABLE_STAT2 is now 
available through SQLITE_ENABLE_STAT3. The enhanced query planning is still 
disabled by default. However, future releases of SQLite might convert STAT3 
from an enable-option to a disable-option so that it is available by default 
and is only omitted upon request.

The FTS4 full-text search engine has been enhanced such that tokens in the 
search string that begin with "^" must be the first token in their respective 
columns in order to match. Formerly, "^" characters in the search string were 
simply ignored. Hence, if a legacy application was including "^" characters in 
FTS4 search strings, thinking that they would always be ignored, then those 
legacy applications might break with this update. The fix is simply remove the 
"^" characters from the search string.

See the change summary for additional changes associated with this release.

2011-September-19 - Version 3.7.8

SQLite version 3.7.8 is a quarterly maintenance release. Upgrading from 
versions 3.7.6.3, 3.7.7, or 3.7.7.1 is optional. Upgrading from other versions 
is recommended.
This release features a new "external merge sort" algorithm used to implement 
ORDER BY and GROUP BY and also to presort the content of an index for CREATE 
INDEX. The new algorithm does approximately the same number of comparisons and 
I/Os as before, but the I/Os are much more sequential and so runtimes are 
greatly reduced when the size of the set being sorted is larger than the 
filesystem cache. The performance improvement can be dramatic - orders of 
magnitude faster for large CREATE INDEX commands. On the other hand, the code 
is slightly slower (1% or 2%) for a small CREATE INDEX. Since CREATE INDEX is 
not an operation that commonly occurs on a speed-critical path, we feel that 
this tradeoff is a good one. The slight slowdown for small CREATE INDEX 
statements might be recovered in a future release. ORDER BY and GROUP BY 
operations should now be faster for all cases, large and small.

The query planner has been enhanced to do a better job of handling the DISTINCT 
keyword on SELECT statements.

There has been a lot of work on the default VFSes. The unix VFS has been 
enhanced to include more overrideable system calls - a feature requested by 
Chromium to make it easier to build SQLite into a sandbox. The windows VFS has 
been enhanced to be more resistant to interference from anti-virus software.

Every version of SQLite is better tested than the previous, and 3.7.8 is no 
exception to this rule. Version 3.7.8 has been used internally by the SQLite 
team for mission critical functions and has performed flawlessly. And, of 
course, it passes our rigorous testing procedures with no problems detected. 
Version 3.7.8 is recommended for all new development.

2011-06-28 - Version 3.7.7.1

SQLite version 3.7.7.1 adds a one-line bug fix to 3.7.7 to fix a problem 
causing PRAGMA case_sensitive_like statements compiled using the legacy 
sqlite3_prepare() interface to fail with an SQLITE_SCHEMA error. Because 
sqlite3_exec() uses sqlite3_prepare() internally, the problem also affects 
sqlite3_exec().
Upgrading from 3.7.7 is only required for applications that use "PRAGMA 
case_sensitive_like" and the sqlite3_prepare() (or sqlite3_exec()) interface.

2011-06-24 - Version 3.7.7

SQLite version 3.7.7 is a regularly scheduled bi-monthly maintenance release. 
Upgrading from version 3.7.6.3 is optional. Upgrading from all prior releases 
is recommended.
This release adds support for naming database files using URI filenames. URI 
filenames are disabled by default (for backwards compatibility) but 
applications are encouraged to enable them since incompatibilities are likely 
to be exceedingly rare and the feature is useful. See the URI filename 
documentation for details.

Most of the other enhancements in this release involve virtual tables. The 
virtual table interface has been enhanced to support SAVEPOINT and ON CONFLICT 
clause processing, and the built-in RTREE and FTS3/FTS4 have been augmented to 
take advantage of the new capability. This means, for example, that it is now 
possible to use the REPLACE command on FTS3/FTS4 and RTREE tables.

The FTS4 full-text index extension has been enhanced to support the FTS4 prefix 
option and the FTS4 order option. These two enhancements are provided in 
support of search-as-you-type interfaces where search results begin to appear 
after the first keystroke in the "search" box and are refined with each 
subsequent keystroke. The way this is done is to do a separate full-text search 
after each key stroke, and add the "*" wildcard at the end of the word 
currently being typed. So, for example, if the text typed so far is "fast da" 
and the next character typed is "t", then the application does a full-text 
search of the pattern "fast dat*" and displays the results. Such capability has 
always existed. What is new is that the FTS4 prefix option allows the search to 
be very fast (a matter of milliseconds) even for difficult cases such as "t*" 
or "th*".

There has been a fair amount of work done on the FTS4 module for this release. 
But the core SQLite code has changed little and the previous release has not 
given any problems, so we expect this to be a very stable release.

2011-05-19 - Version 3.7.6.3

SQLite version 3.7.6.3 is a patch release that fixes a single bug associated 
with WAL mode. The bug has been in SQLite ever since WAL was added, but the 
problem is very obscure and so nobody has noticed before now. Nevertheless, all 
users are encouraged to upgrade to version 3.7.6.3 or later.
The bug is this: If the cache_size is set very small (less than 10) and SQLite 
comes under memory pressure and if a multi-statement transaction is started in 
which the last statement prior to COMMIT is a SELECT statement and if a 
checkpoint occurs right after the transaction commit, then it might happen that 
the transaction will be silently rolled back instead of being committed.

The default setting for cache_size is 2000. So in most situations, this bug 
will never appear. But sometimes programmers set cache_size to very small 
values on gadgets and other low-memory devices in order to save memory space. 
Such applications are vulnerable. Note that this bug does not cause database 
corruption. It is as if ROLLBACK were being run instead of COMMIT in some cases.

Bug Details

Transactions commit in WAL mode by adding a record onto the end of the WAL (the 
write-ahead log) that contains a "commit" flag. So to commit a transaction, 
SQLite takes all the pages that have changed during that transaction, appends 
them to the WAL, and sets the commit flag on the last page. Now, if SQLite 
comes under memory pressure, it might try to free up memory space by writing 
changed pages to the WAL prior to the commit. We call this "spilling" the cache 
to WAL. There is nothing wrong with spilling cache to WAL. But if the memory 
pressure is severe, it might be that by the time COMMIT is run, all changed 
pages for the transaction have already been spilled to WAL and there are no 
pages left to be written to WAL. And with no unwritten pages, there was nothing 
to put the commit flag on. And without a commit flag, the transaction would end 
up being rolled back.

The fix to this problem was that if all changed pages has already been written 
to the WAL when the commit was started, then page 1 of the database will be 
written to the WAL again, so that there will always be a page available on 
which to set the commit flag.

2011-04-17 - Version 3.7.6.2

SQLite version 3.7.6.2 adds a one-line bug fix to 3.7.6.1 that enables pthreads 
to work correctly on NetBSD. The problem was a faulty function signature for 
the open system call. The problem does not appear to have any adverse impact on 
any system other than NetBSD.
Upgrading from version 3.7.6.1 is only needed on NetBSD.

2011-04-13 - Version 3.7.6.1

SQLite version 3.7.6.1 fixes a single bug in 3.7.6 that can cause a segfault if 
SQLITE_FCNTL_SIZE_HINT is used on a unix build that has 
SQLITE_ENABLE_LOCKING_MODE set to 0 and is compiled with HAVE_POSIX_FALLOCATE.
Upgrading from 3.7.6 is only needed for users effected by the 
configuration-specific bug described above. There are no other changes to the 
code.

2011-04-12 - Version 3.7.6

SQLite version 3.7.6 is a regularly scheduled bi-monthly maintenance release of 
SQLite. Upgrading from version 3.7.5 is optional. Upgrading releases prior to 
3.7.5 is recommended.
2011-02-01 - Version 3.7.5

SQLite version 3.7.5 is a regularly scheduled bi-monthly maintenance release of 
SQLite. Due to the discovery and fix of an obscure bug that could cause 
database corruption, upgrading from all prior releases of SQLite is 
recommended. This bug was found during code review and has not been observed in 
the wild.
This release adds new opcodes for the sqlite3_db_status() interface that allow 
more precise measurement of how the lookaside memory allocator is performing, 
which can be useful for tuning in applications with very tight memory 
constraints.

The sqlite3_vsnprintf() interface was added. This routine is simply a varargs 
version of the long-standing sqlite3_snprintf() interface.

The output from sqlite3_trace() interface has been enhanced to work better (and 
faster) in systems that use recursive extensions such as FTS3 or RTREE.

Testing with Valgrind shows that this release of SQLite is about 1% or 2% 
faster than the previous release for most operations.

A fork of the popular ADO.NET adaptor for SQLite known as System.Data.SQLite is 
now available on http://System.Data.SQLite.org/. The originator of 
System.Data.SQLite, Robert Simpson, is aware of this fork, has expressed his 
approval, and has commit privileges on the new Fossil repository. The SQLite 
development team intends to maintain System.Data.SQLite moving forward.

2010-12-08 - Version 3.7.4

SQLite version 3.7.4 is a regularly scheduled bi-monthly maintenance release of 
SQLite. Upgrading from version 3.7.2 and version 3.7.3 is optional. Upgrading 
from all other SQLite releases is recommended.
This release features full-text search enhancements. The older FTS3 virtual 
table is still fully supported, and should also run faster. In addition, the 
new FTS4 virtual table is added. FTS4 follows the same syntax as FTS3 but holds 
additional metadata which facilitates some performance improvements and more 
advanced matchinfo() output. Look for further full-text search enhancements in 
subsequent releases.

Also in this release, the EXPLAIN QUERY PLAN output has been enhanced and new 
documentation is provided so that application developers can more easily 
understand how SQLite is performing their queries.

Thanks to an account from the folks at http://www.devio.us/, OpenBSD has been 
added to the list of platforms upon which we test SQLite prior to every 
release. That list of platforms now includes:

Linux x86 & x86_64
MacOS 10.5 & 10.6
MacOS 10.2 PowerPC
WinXP and Win7
Android 2.2
OpenBSD 4.7
The previous release of SQLite (version 3.7.3) has proven to be very robust. 
The only serious issue discovered was ticket 80ba201079 that describes an 
incorrect query result that can occur under very unusual circumstances. The 
ticket description contains details of the problem. Suffice it to say here that 
the problem is very obscure and is unlikely to effect most applications and so 
upgrading is optional. The problem is fixed, of course, in this release.

2010-October-08 - Version 3.7.3

SQLite version 3.7.3 is a regularly scheduled bi-monthly maintenance release of 
SQLite. Upgrading from version 3.7.2 is optional. Upgrading from all other 
releases is recommended.
This release adds two new interfaces (really just variations on existing 
interfaces). The sqlite3_create_function_v2() interface adds a destructor for 
the application-data pointer. The new sqlite3_soft_heap_limit64() interface 
allows the soft heap limit to be set to a value greater than 231.

The RTREE extension has been enhanced with the ability to have an 
application-defined query region. This might be used, for example, to locate 
all objects within the field of view of a camera.

The 3.7.3 release also includes some performance enhancements, including query 
planner improvements, documentation updates, and fixes to some very obscure 
bugs.

2010-August-24 - Version 3.7.2

SQLite version 3.7.2 fixes a long-standing bug that can cause the database 
free-page list to go corrupt if incremental_vacuum is used multiple times to 
partially reduce the size of a database file that contains many hundreds of 
unused database pages. The original bug reports together with links to the 
patch that fixes it can be seen here.
This bug has been in the code for at least a year and possibly longer. The bug 
has nothing to do with the versions 3.7.1 or 3.7.0 or any other recent release. 
The fact that the bug was discovered (and fixed) within hours of the 3.7.1 
release is purely a coincidence.

The bug is impossible to hit without using incremental_vacuum and is very 
difficult to hit even with incremental_vacuum. And the kind of corruption that 
the bug causes can usually be fixed simply by running VACUUM. Nevertheless, 
because the bug can result in database corruption, it is recommended that all 
SQLite users upgrade to version 3.7.2 or later.

2010-August-23 - Version 3.7.1

SQLite version 3.7.1 is a stabilization release for the 3.7.x series. Other 
than the filesize-in-header bug that was fixed in version 3.7.0.1, no major 
problems have been seen in 3.7.0. Some minor corner-case performance 
regressions have been fixed. A typo in the OS/2 interface has been repaired.
A biggest part of the 3.7.1 release is a cleanup and refactoring of the pager 
module within SQLite. This refactoring should have no application-visible 
effects. The purpose was to reorganize the code in ways that make it easier to 
prove correctness.

The 3.7.1 release adds new experimental methods for obtained more detailed 
memory usage information and for controlling database file fragmentation. And 
the query planner now does a better job of optimizing the LIKE and GLOB 
operators.

This release increases the maximum size of database pages from 32KiB to 64KiB. 
A database with 64KiB pages will not be readable or writable by older versions 
of SQLite. Note that further increases in page size are not feasible since the 
file format uses 16-bit offsets to structures within each page.

2010-August-04 - Version 3.7.0.1

SQLite version 3.7.0.1 is a patch release to fix a bug in the new 
filesize-in-header feature of the SQLite file format that could cause database 
corruption if the same database file is written alternately with version 3.7.0 
and version 3.6.23.1 or earlier. A performance regression was also fixed in 
this release.
2010-07-22 - Version 3.7.0

SQLite version 3.7.0 is a major release of SQLite that features a new 
transaction control mechanism using a write-ahead log or WAL. The traditional 
rollback-journal is still used as the default so there should be no visible 
change for legacy programs. But newer programs can take advantage of improved 
performance and concurrency by enabling the WAL journaling mode.
SQLite version 3.7.0 also contains some query planner enhancements and a few 
obscure bug fixes, but the only really big change is the addition of WAL mode.

2010-03-30 - Version 3.6.23.1

SQLite version 3.6.23.1 is a patch release to fix a bug in the offsets() 
function of FTS3 at the request of the Mozilla.
2010-03-09 - Version 3.6.23

SQLite version 3.6.23 is a regular bimonthly release of SQLite. Upgrading from 
the prior release is purely optional.
This release contains new pragmas: the secure_delete pragma, and the 
compile_options pragma. There are a new SQL functions: 
sqlite_compileoption_used() and sqlite_compileoption_get(). New C/C++ 
interfaces: sqlite3_compileoption_used(), sqlite3_compileoption_get(), 
SQLITE_CONFIG_LOG, and sqlite3_log().

This release also includes several minor bug fixes and performance 
improvements. Support for SQLITE_OMIT_FLOATING_POINT is enhanced. There are 
on-going improvements to FTS3.

The ".genfkey" command in the Command Line Interface has been removed. SQLite 
has supported standard SQL foreign key constraints since version 3.6.19 and so 
the ".genfkey" command was seen as an anachronism.

2010-01-06 - Version 3.6.22

SQLite version 3.6.22 is a bug-fix release. Two bugs have been fixed that might 
cause incorrect query results.
Ticket 31338dca7e describes a problem with queries that have a WHERE clause of 
the form (x AND y) OR z where x and z come from one table of a join and y comes 
from a different table.
Ticket eb5548a849 describes a problem where the use of the CAST operator in the 
WHERE clause can lead to incorrect results if the column being cast to a new 
datatype is also used in the same WHERE clause without being cast.
Both bugs are obscure, but because they could arise in an application after 
deployment, it is recommended that all applications upgrade SQLite to version 
3.6.22.
This release also includes other minor bug fixes and performance enhancements, 
especially in the FTS3 extension.

2009-12-07 - Version 3.6.21

SQLite version 3.6.21 focuses on performance optimization. For a certain set of 
traces, this version uses 12% fewer CPU instructions than the previous release 
(as measured by Valgrind). In addition, the FTS3 extension has been through an 
extensive cleanup and rework and the sqlite3_trace() interface has been 
modified to insert bound parameter values into its output.
2009-11-04 - Version 3.6.20

SQLite version 3.6.20 is a general maintenance release. The query planner has 
been enhanced to work better with bound parameters in LIKE and GLOB operators 
and in range constraints and various minor bugs have been fixed. Upgrading from 
3.6.19 is optional.
2009-10-14 - Version 3.6.19

SQLite version 3.6.19 adds native support for foreign key constraints, 
including deferred constraints and cascading deletes. Enforcement of foreign 
keys is disabled by default for backwards compatibility and must be turned on 
using the foreign_keys pragma.
Version 3.6.19 also adds support for the IS and IS NOT operators. Formerly, 
SQLite (as most other SQL database engines) supported IS NULL and IS NOT NULL. 
The IS and IS NOT operators are generalizations that allow the right-hand side 
to be an arbitrary expression. IS and IS NOT work the same as == (equals) and 
!= (not equals) except that with IS and IS NOT the NULL values compare equal to 
one another.

2009-09-11 - Version 3.6.18

Beginning with this release, the SQLite source code is tracked and managed 
using the Fossil distributed configuration management system. SQLite was 
previously versioned using CVS. The entire CVS history has been imported into 
Fossil. The older CVS repository remains on the website but is read-only.
There are two major enhancements in SQLite version 3.6.18. The first is a 
series or refinements to the query planner that help SQLite to choose better 
plans for joins where in the past it was selecting suboptimal query plans. The 
SQLITE_ENABLE_STAT2 compile-time option has been added to cause SQLite to 
collect histogram data on indices when the ANALYZE command is run. The use of 
histograms improve the query planning performance even more.

The second major enhancement is that SQLite now support recursive triggers. The 
older non-recursive behavior of triggers is still the default behavior. 
Recursive triggers are activated using the recursive_triggers pragma. In 
addition to allowing triggers to call themselves (either directly or 
indirectly) the new capability also fires DELETE triggers on rows that are 
removed from a table as a result of REPLACE conflict resolution processing.

Non-recursive triggers are still the default behavior since this is least 
likely to cause problems for existing applications. However, we anticipate that 
triggers will become recursive by default beginning with release 3.7.0. At that 
point, applications that want to continue using the older non-recursive trigger 
behavior will need to use the recursive_triggers pragma to disable recursive 
triggers.

This version of SQLite also contains bug fixes, though none of the bugs are 
serious and all are obscure, so upgrading is optional.

The SQLite core continues to have 100% branch test coverage and so despite the 
many changes in this release, the developers believe that this version of 
SQLite is stable and ready for production use.

2009-08-10 - Version 3.6.17

This is a monthly maintenance release with a focus of bug fixes, performance 
improvements, and increased test coverage. This is the first release of SQLite 
since 100% branch test coverage was achieved on the SQLite core.
In addition, a new interface sqlite3_strnicmp() is provided for the convenience 
of extension writers.

None of the bugs fixed in this release are serious. All bugs are obscure. 
Upgrading is optional.

2009-07-25 - 100% Branch Test Coverage

A subset of the TH3 test suite was measured by gcov to provide 100% branch test 
coverage over the SQLite core (exclusive of the VFS backend and of extensions 
such as FTS3 and RTREE) when compiled for SuSE 10.1 Linux on x86. The SQLite 
developers pledge to maintain branch test coverage at 100% in all future 
releases. Ongoing work will strive for 100% branch test coverage on the 
operating-system backends and extensions as well.
2009-06-27 - Version 3.6.16

SQLite version 3.6.16 is another general maintenance release containing 
performance and robustness enhancements. A single notable bug was fixed (ticket 
#3929). This bug cause cause INSERT or UPDATE statements to fail on indexed 
tables that have AFTER triggers that modify the same table and index.
2009-06-15 - Version 3.6.15

SQLite version 3.6.15 is a general maintenance release containing performance 
and robustness enhancements and fixes for various obscure bugs.
2009-05-25 - Version 3.6.14.2

SQLite version 3.6.14.2 fixes an obscure bug in the code generator (ticket 
#3879) section of SQLite which can potentially cause incorrect query results. 
The changes from the prior release consist of only this one bug fix, check-in 
[6676] and a change to the version number text.
The bug was introduced in version 3.6.14. It is recommended that users of 
version 3.6.14 and 3.6.14.1 upgrade to this release. Applications are unlikely 
to hit this bug, but since it is difficult to predict which applications might 
hit it and which might not, we recommend that all users of 3.6.14 and 3.5.14.1 
upgrade to this release.

2009-05-19 - Version 3.6.14.1

SQLite version 3.6.14.1 is a patch release to version 3.6.14 with minimal 
changes that fixes three bugs. Upgrading is only necessary for users who are 
impacted by one or more of those bugs.
2009-05-07 - Version 3.6.14

SQLite version 3.6.14 provides new performance enhancements in the btree and 
pager layers and in the query optimizer. Certain workloads can be as much as 
twice as fast as the previous release, though 10% faster is a more typical 
result.
Queries against virtual tables that contain OR and IN operators in the WHERE 
clause are now able to use indexing.

A new optional asynchronous I/O backend is available for unix and windows. The 
asynchronous backend gives the illusion of faster response time by pushing slow 
write operations into a background thread. The tradeoff for faster response 
time is that more memory is required (to hold the content of the pending 
writes) and if a power failure or program crash occurs, some transactions that 
appeared to have committed might end up being rolled back upon restart.

This release also contains many minor bug fixes, documentation enhancements, 
new test cases, and cleanups and simplifications to the source code.

There is no compelling reason to upgrade from versions 3.6.12 or 3.6.13 if 
those prior versions are working. Though many users may benefit from the 
improved performance.

Status:

Vendor Tag:     SQLITE
Release Tags:   sqlite-3-8-3-1
                
U src/external/public-domain/sqlite/dist/shell.c
C src/external/public-domain/sqlite/dist/sqlite3.c
U src/external/public-domain/sqlite/dist/sqlite3ext.h
U src/external/public-domain/sqlite/dist/sqlite3.h

1 conflicts created by this import.
Use the following command to help the merge:

        cvs checkout -jSQLITE:yesterday -jSQLITE 
src/external/public-domain/sqlite/dist