<title>Recent SQLite News</title>
<h2>Recent News</h2>
<tcl>
proc newsitem {date title text} {
regsub -all {[^a-z0-9]} [string tolower $date] _ tag
hd_puts "<a name=\"$tag\"></a>"
if {![regsub -all {(Version) (\d+)\.(\d+)\.(\d+)\.(\d+)} $title \
{<a href="releaselog/\2_\3_\4_\5.html">\0</a>} title]} {
regsub -all {(Version) (\d+)\.(\d+)\.(\d+)} $title \
{<a href="releaselog/\2_\3_\4.html">\0</a>} title
}
hd_puts "<h3>$date - $title</h3>"
regsub -all "\n( *\n)+" $text "</p>\n\n<p>" txt
regsub -all {[Tt]icket #(\d+)} $txt \
{<a href="http://www.sqlite.org/cvstrac/tktview?tn=\1">\0</a>} txt
hd_resolve "<blockquote>$txt</blockquote>"
hd_puts "<hr width=\"50%\">"
}
newsitem {2014-04-03} {Release 3.8.4.3} {
<p>The optimizations added in [version 3.8.4] caused some queries that involve
subqueries in the FROM clause, DISTINCT, and ORDER BY clauses, to give an incorrect
result. See
[http://www.sqlite.org/src/info/98825a79ce145686392d8074032ae54863aa21a3| ticket 98825a79ce145]
for details.
This release adds a
[http://www.sqlite.org/src/fdiff?sbs=1&v1=7d539cedb1c&v2=ebad891b7494d&smhdr|one-character change]
to a single line of code to fix the problem.
}
newsitem {2014-03-26} {Release 3.8.4.2} {
<p>The code changes that resulted in the performance improvements
in [version 3.8.4] missed a single buffer overflow test, which could
result in a read past the end of a buffer while searching a database
that is corrupted in a particular way. [Version 3.8.4.2] fixes that
problem using a
[http://www.sqlite.org/src/fdiff?v1=e45e3f9daf38c5be&v2=714df4e1c82f629d&sbs=1|one-line patch].
<p>We are not aware of any problems in [version 3.8.4]
when working with well-formed database files. The problem fixed by this
release only comes up when reading corrupt database files.
}
newsitem {2014-03-11} {Release 3.8.4.1} {
<p>SQLite [version 3.8.4.1] is a patch against [version 3.8.4] that fixes
two minor issues:
<ol>
<li> Work around a C-preprocessor macro conflict that causes compilation
problems for some configurations of Visual Studio.
<li> Adjust the cost computation for the [skip-scan optimization] for
improved performance.
</ol>
Both of these issues came to light within minutes of tagging the previous
release. Neither issue is serious but they can be annoying. Hence, the
decision was made to do a quick patch release to address both issues.
}
newsitem {2014-03-10} {Release 3.8.4} {
<p>SQLite [version 3.8.4] is a maintenance release featuring performance
enhancements and fixes for a number of obscure bugs.
There are no significant new features in SQLite version 3.8.4.
However, the number of CPU cycles (measured by valgrind) needed to
do many common operations has be reduced by about 12% relative to the
previous release, and by about 25% relative to [version 3.7.16]
from approximately one year ago.
<p>Version 3.8.4 of SQLite fixes several corner-case bugs that were
found since the previous release. These bugs were unlikely to appear
in practice, and none represent a security vulnerability.
Nevertheless, developers are encouraged to upgrade from all prior releases.
}
newsitem {2014-02-11} {Release 3.8.3.1} {
<p>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 output rows.
Upgrading from those versions is recommended.
<p>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:
<blockquote>
WHERE (expr1 OR expr2 OR ... OR exprN) AND column IS NOT NULL
</blockquote>
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.
<p>The trouble ticket for this bug is
[[http://www.sqlite.org/src/info/4c86b126f2|4c86b126f2]].
It is recommended that all users upgrade to avoid this problem.
}
newsitem {2014-02-03} {Release 3.8.3} {
<p>SQLite [version 3.8.3] is a regularly scheduled maintenance release.
Upgrading from the previous release is optional.
<p>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.
<p>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 [version 3.8.3|change log] for details.
}
newsitem {2013-12-06} {Release 3.8.2} {
<p>SQLite [version 3.8.2] is a regularly scheduled maintenance release.
Upgrading from the previous release is optional.
<p>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.
<p>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.
<p>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.
}
newsitem {2013-10-17} {Release 3.8.1} {
<p>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
[http://www.sqlite.org/src/info/a5c8ed66ca|bug] related to partial
indices in the previous release that could result in an incorrect answer
for count(*) queries.
<p>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.
<p>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|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.
<p>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.
}
newsitem {2013-09-03} {Release 3.8.0.2} {
<p>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.
}
newsitem {2013-08-29} {Release 3.8.0.1} {
<p>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.
}
newsitem {2013-08-26} {Release 3.8.0} {
<b>Do not fear the zero!</b>
<p>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
[hazards of upgrading to the NGQP | 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.
<p>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.
<p>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 [version 3.8.0 | change log] for further detail.
}
newsitem {2013-05-20} {Release 3.7.17} {
SQLite [version 3.7.17] is a regularly schedule maintenance release.
Visit the [version 3.7.17 | 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.
}
newsitem {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.
}
newsitem {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 [http://www.sqlite.org/src/info/a179fe7465 | 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.
}
newsitem {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 [version 3.7.16 | change log].
There was one important bug fix
(see [http://www.sqlite.org/src/info/fc7bd6358f | 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.
}
newsitem {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].
}
</tcl>
<a href="oldnews.html">Old news...</a>