New in version 184.108.40.206
November 19th, 2014
- The primary reason for this release is to enhance the ROLLBACK command so that it allows running queries on the same database connection to continue running as long as the ROLLBACK does not change the schema. In all previous versions of SQLite, a ROLLBACK would cause pending queries to stop immediately and return SQLITE_ABORT or SQLITE_ABORT_ROLLBACK. Pending queries still abort if the ROLLBACK changes the database schema, but as of this patch release, the queries are allowed to continue running if the schema is unmodified.
- In addition to the ROLLBACK enhancement, this patch release also includes fixes for three obscure bugs.
New in version 220.127.116.11 (October 30th, 2014)
- The primary reason for this bug-fix release is to address a problem with updating the value of fields at the end of a table that were added using ALTER TABLE ADD COLUMN. This problem 1 first appeared in the 3.8.7 release.
- Another minor annoyance in the 3.8.7 release was the fact that the Android build tried to use the strchrnul() function from the standard C library but that function is not available on Android. Android builds had to add -DHAVE_STRCHRNUL=0 to work around the problem. This patch fixes that so that Android builds should now work without any changes.
- The operation of PRAGMA journal_mode=TRUNCATE has been enhanced so that it invokes fsync() after truncating the journal file when PRAGMA synchronous=FULL. This helps to preserve transaction durability in the case of a power loss occurring shortly after commit.
- Finally, a couple of long-standing and obscure problems associated with run UPDATE and DELETE on VIEWs were fixed.
New in version 3.8.7 (October 17th, 2014)
- Most of the changes from the previous release have been micro-optimizations designed to help SQLite run a little faster. Each individual optimization has an unmeasurably small performance impact. But the improvements add up. Measured on a well-defined workload (which the SQLite developers use as a proxy for a typical application workload) using cachegrind on Linux and compiled with gcc 4.8.1 and -Os on x64 linux, the current release does over 20% more work for the same number of CPU cycles compared to the previous release. Cachegrind is not a real CPU, and the workload used for measurement is only a proxy. So your performance may vary. We expect to see about half the measured and reported improvement in real-world applications. 10% is less than 20% but it is still pretty good, we think.
- This release includes a new set of C-language interfaces that have unsigned 64-bit instead of signed 32-bit length parameters. The new APIs do not provide any new capabilities. But they do make it easier to write applications that are more resistant to integer overflow vulnerabilities.
- This release also includes a new sorter that is able to use multiple threads to help with large sort operations. (Sort operations are sometimes required to implement ORDER BY and/or GROUP BY clauses and are almost always required for CREATE INDEX.) The multi-threads sorter is turned off by default and must be enabled using the PRAGMA threads SQL command. Note that the multi-threaded sorter provides faster real-time performance for large sorts, but it also uses more CPU cycles and more energy.
New in version 18.104.22.168 (February 12th, 2014)
- SQLite version 22.214.171.124 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.
New in version 3.8.3 (February 4th, 2014)
- Added support for common table expressions and the WITH clause.
- Added the printf() SQL function.
- Added SQLITE_DETERMINISTIC as an optional bit in the 4th argument to the sqlite3_create_function() and related interfaces, providing applications with the ability to create new functions that can be factored out of inner loops when they have constant arguments.
- Add SQLITE_READONLY_DBMOVED error code, returned at the beginning of a transaction, to indicate that the underlying database file has been renamed or moved out from under SQLite.
- Allow arbitrary expressions, including function calls and subqueries, in the filename argument to ATTACH.
- Allow a VALUES clause to be used anywhere a SELECT statement is valid.
- Reseed the PRNG used by sqlite3_randomness(N,P) when invoked with N==0. Automatically reseed after a fork() on unix.
- Enhance the spellfix1 virtual table so that it can search efficiently by rowid.
- Performance enhancements.
- Improvements to the comments in the VDBE byte-code display when running EXPLAIN.
- Add the "%token_class" directive to LEMON parser generator and use it to simplify the grammar.
- Change the LEMON source code to avoid calling C-library functions that OpenBSD considers dangerous. (Ex: sprintf).
- Bug fix: In the command-line shell CSV import feature, do not end a field when an escaped double-quote occurs at the end of a CRLN line.
- SQLITE_SOURCE_ID: "2014-02-03 13:52:03 e816dd924619db5f766de6df74ea2194f3e3b538"
- SHA1 for sqlite3.c: 98a07da78f71b0275e8d9c510486877adc31dbee
New in version 3.8.2 (December 6th, 2013)
- 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.
New in version 3.8.1 (October 18th, 2013)
- 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.
New in version 126.96.36.199 (August 31st, 2013)
- SQLite version 188.8.131.52 fixes some obscure bugs that were uncovered by users in the 3.8.0 release. Changes from 3.8.0 are minimal.
New in version 3.8.0 (August 26th, 2013)
- Add support for partial indexes
- Cut-over to the next generation query planner for faster and better query plans.
- The EXPLAIN QUERY PLAN output no longer shows an estimate of the number of rows generated by each loop in a join.
- Added the FTS4 notindexed option, allowing non-indexed columns in an FTS4 table.
- Added the SQLITE_STMTSTATUS_VM_STEP option to sqlite3_stmt_status().
- Added the cache_spill pragma.
- Added the query_only pragma.
- Added the defer_foreign_keys pragma and the sqlite3_db_status(db, SQLITE_DBSTATUS_DEFERRED_FKS,...) C-language interface.
- Added the "percentile()" function as a loadable extension in the ext/misc subdirectory of the source tree.
- Added the SQLITE_ALLOW_URI_AUTHORITY compile-time option.
- Add the sqlite3_cancel_auto_extension(X) interface.
- A running SELECT statement that lacks a FROM clause (or any other statement that never reads or writes from any database file) will not prevent a read transaction from closing.
- Add the SQLITE_DEFAULT_AUTOMATIC_INDEX compile-time option. Setting this option to 0 disables automatic indices by default.
- Issue an SQLITE_WARNING_AUTOINDEX warning on the SQLITE_CONFIG_LOG whenever the query planner uses an automatic index.
- Added the SQLITE_FTS3_MAX_EXPR_DEPTH compile-time option.
- Added an optional 5th parameter defining the collating sequence to the next_char() extension SQL function.
- The SQLITE_BUSY_SNAPSHOT extended error code is returned in WAL mode when a read transaction cannot be upgraded to a write transaction because the read is on an older snapshot.
- Enhancements to the sqlite3_analyzer utility program to provide size information separately for each individual index of a table, in addition to the aggregate size.
- Allow read transactions to be freely opened and closed by SQL statements run from within the implementation of application-defined SQL functions if the function is called by a SELECT statement that does not access any database table.
- Disable the use of posix_fallocate() on all (unix) systems unless the HAVE_POSIX_FALLOCATE compile-time option is used.
- Update the ".import" command in the command-line shell to support multi-line fields and correct RFC-4180 quoting and to issue warning and/or error messages if the input text is not strictly RFC-4180 compliant.
- Bug fix: In the unicode61 tokenizer of FTS4, treat all private code points as identifier symbols.
- Bug fix: Bare identifiers in ORDER BY clauses bind more tightly to output column names, but identifiers in expressions bind more tightly to input column names. Identifiers in GROUP BY clauses always prefer output column names, however.
- Bug fixes: Multiple problems in the legacy query optimizer were fixed by the move to NGQP.
- SQLITE_SOURCE_ID: "2013-08-26 04:50:08 f64cd21e2e23ed7cff48f7dafa5e76adde9321c2"
- SHA1 for sqlite3.c: b7347f4b4c2a840e6ba12040093d606bd16ea21e