Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Changes In Branch branch-3.24-https Excluding Merge-Ins
This is equivalent to a diff from 27b8057665 to 59e5f9e3da
2018-06-09
| ||
22:13 | Fix typos in the compile.html page. (check-in: 10c05df9fb user: drh tags: branch-3.24) | |
2018-06-08
| ||
13:21 | Use https for all internal hyperlinks. (Leaf check-in: 59e5f9e3da user: drh tags: branch-3.24-https) | |
2018-06-05
| ||
23:20 | Clarification that the overwrite optimization does not affect the behavior of triggers. (check-in: 27b8057665 user: drh tags: branch-3.24) | |
2018-06-04
| ||
19:41 | Add the upsert-clause.gif image. (check-in: 7d927bcea1 user: drh tags: trunk) | |
Changes to pages/about.in.
︙ | ︙ | |||
77 78 79 80 81 82 83 | even if interrupted by system crashes or power failures. All of this is verified by the automated tests using special test harnesses which simulate system failures. Of course, even with all this testing, there are still bugs. But unlike some similar projects (especially commercial competitors) SQLite is open and honest about all bugs and provides | | | | 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 | even if interrupted by system crashes or power failures. All of this is verified by the automated tests using special test harnesses which simulate system failures. Of course, even with all this testing, there are still bugs. But unlike some similar projects (especially commercial competitors) SQLite is open and honest about all bugs and provides <a href="https://www.sqlite.org/src/rptview?rn=1">bugs lists</a> and minute-by-minute <a href="https://www.sqlite.org/src/timeline"> chronologies</a> of code changes.</p> <p>The SQLite code base is supported by an <a href="crew.html">international team</a> of developers who work on SQLite full-time. The developers continue to expand the capabilities of SQLite and enhance its reliability and performance while maintaining |
︙ | ︙ |
Changes to pages/affcase1.in.
︙ | ︙ | |||
236 237 238 239 240 241 242 | Surprisingly, using SQLite in place of ZIP makes the presentation file smaller. Really. One would think that a relational database file would be larger than a ZIP archive, but at least in the case of NeoOffice that is not so. The following is an actual screen-scrape showing the sizes of the same NeoOffice presentation, both in its original ZIP archive format as generated by NeoOffice (self2014.odp), and as repacked as an SQLite database using the | | | 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 | Surprisingly, using SQLite in place of ZIP makes the presentation file smaller. Really. One would think that a relational database file would be larger than a ZIP archive, but at least in the case of NeoOffice that is not so. The following is an actual screen-scrape showing the sizes of the same NeoOffice presentation, both in its original ZIP archive format as generated by NeoOffice (self2014.odp), and as repacked as an SQLite database using the [https://www.sqlite.org/sqlar/doc/trunk/README.md|SQLAR] utility: <blockquote><pre> -rw-r--r-- 1 drh staff 10514994 Jun 8 14:32 self2014.odp -rw-r--r-- 1 drh staff 10464256 Jun 8 14:37 self2014.sqlar -rw-r--r-- 1 drh staff 10416644 Jun 8 14:40 zip.odp </pre></blockquote> |
︙ | ︙ |
Changes to pages/amalgamation.in.
︙ | ︙ | |||
149 150 151 152 153 154 155 | <p>In both cases, the split amalgamation can be obtained by substituting "sqlite3-all.c" for "sqlite3.c" as the make target. <h2>Dependencies</h2> <p>The build process makes extensive use of the | | | | 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 | <p>In both cases, the split amalgamation can be obtained by substituting "sqlite3-all.c" for "sqlite3.c" as the make target. <h2>Dependencies</h2> <p>The build process makes extensive use of the [http://www.tcl.tk/|Tcl] scripting language. You will need to have a copy of TCL installed in order for the make targets above to work. Easy-to-use installers can be obtained from [http://www.tcl.tk/]. Many unix workstations have Tcl installed by default. <h2>See Also</h2> <p>Additional notes on compiling SQLite can be found on the [How To Compile SQLite] page. |
Changes to pages/appfileformat.in.
︙ | ︙ | |||
277 278 279 280 281 282 283 | <p>SQLite is transactional, meaning that multiple changes can be grouped together such that either all or none of them occur, and so that the changes can be rolled back if a problem is found prior to commit. This allows an application to make a change incrementally, then run various sanity and consistency checks on the resulting data prior to committing the changes to disk. The | | | | 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 | <p>SQLite is transactional, meaning that multiple changes can be grouped together such that either all or none of them occur, and so that the changes can be rolled back if a problem is found prior to commit. This allows an application to make a change incrementally, then run various sanity and consistency checks on the resulting data prior to committing the changes to disk. The [https://www.fossil-scm.org/ | Fossil] DVCS [https://www.fossil-scm.org/fossil/doc/tip/www/selfcheck.wiki|uses this technique] to verify that no repository history has been lost prior to each change. <li><p><b>Incremental And Continuous Updates.</b> When writing to an SQLite database file, only those parts of the file that actually change are written out to disk. This makes the writing happen faster and saves wear on SSDs. This is an enormous advantage over custom and wrapped pile-of-files formats, both of which usually require a |
︙ | ︙ |
Changes to pages/asyncvfs.in.
︙ | ︙ | |||
118 119 120 121 122 123 124 | <h2>2.0 COMPILATION AND USAGE</h2> <p> The asynchronous IO extension consists of a single file of C code (sqlite3async.c), and a header file (sqlite3async.h), located in the | | | 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 | <h2>2.0 COMPILATION AND USAGE</h2> <p> The asynchronous IO extension consists of a single file of C code (sqlite3async.c), and a header file (sqlite3async.h), located in the <a href="https://www.sqlite.org/src/dir?name=ext/async"> <tt>ext/async/</tt> subfolder</a> of the SQLite source tree, that defines the C API used by applications to activate and control the modules functionality. <p> To use the asynchronous IO extension, compile sqlite3async.c as part of the application that uses SQLite. Then use the APIs defined |
︙ | ︙ | |||
144 145 146 147 148 149 150 | sqlite3async_run(). <li><p>Use the normal SQLite API to read and write to databases via the asynchronous IO VFS. </ol> <p>Refer to comments in the | | | 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 | sqlite3async_run(). <li><p>Use the normal SQLite API to read and write to databases via the asynchronous IO VFS. </ol> <p>Refer to comments in the <a href="https://www.sqlite.org/src/finfo?name=ext/async/sqlite3async.h"> sqlite3async.h header file</a> for details. <h2>3.0 PORTING</h2> <p>Currently the asynchronous IO extension is compatible with win32 systems and systems that support the pthreads interface, including Mac OS X, Linux, |
︙ | ︙ |
Changes to pages/books.in.
︙ | ︙ | |||
286 287 288 289 290 291 292 | <p>SQLite is a small, zero-configuration, custom-tailored, embeddable, thread-safe, easily maintainable, transaction-oriented, SQL-based, relational database management system. There is no separate install or setup procedure to initialize SQLite before using it. There is no configuration file. SQLite is open source, and is available in the public domain (for more information on open source, visit http://opensource.org). | | | 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 | <p>SQLite is a small, zero-configuration, custom-tailored, embeddable, thread-safe, easily maintainable, transaction-oriented, SQL-based, relational database management system. There is no separate install or setup procedure to initialize SQLite before using it. There is no configuration file. SQLite is open source, and is available in the public domain (for more information on open source, visit http://opensource.org). You can download SQLite source code from its homepage https://www.sqlite.org, compile it using your favorite C compiler, and start using the compiled library. SQLite runs on Linux, Windows, Mac OS X, and a few other operating systems. It has been widely used in low-to-medium tier database applications. This Short Cut discusses design principles, engineering trade-offs, implementation issues, and operations of SQLite. It presents a comprehensive description of all important components of the SQLite engine.</p> </table> |
︙ | ︙ |
Changes to pages/changes.in.
1 2 3 4 5 6 7 | <title>Release History Of SQLite</title> <tcl>hd_keywords {release history} {complete list of SQLite releases}</tcl> <h1 align=center>Release History</h1> <p> This page provides a high-level summary of changes to SQLite. For more detail, see the Fossil checkin logs at | | | | | | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | <title>Release History Of SQLite</title> <tcl>hd_keywords {release history} {complete list of SQLite releases}</tcl> <h1 align=center>Release History</h1> <p> This page provides a high-level summary of changes to SQLite. For more detail, see the Fossil checkin logs at <a href="https://www.sqlite.org/src/timeline"> https://www.sqlite.org/src/timeline</a> and <a href="https://www.sqlite.org/src/timeline?t=release"> https://www.sqlite.org/src/timeline?t=release</a>. See the [chronology] a succinct listing of releases. </p> <tcl> set nChng 0 proc chng {date desc {options {}}} { global nChng aChng xrefChng |
︙ | ︙ | |||
1328 1329 1330 1331 1332 1333 1334 | to 100 pages. Yields about a 5% performance increase on common workloads. <li>Miscellaneous micro-optimizations result in 22.3% more work for the same number of CPU cycles relative to the previous release. SQLite now runs twice as fast as [version 3.8.0] and three times as fast as [version 3.3.9]. (Measured using [http://valgrind.org/docs/manual/cg-manual.html|cachegrind] on the | | | 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 | to 100 pages. Yields about a 5% performance increase on common workloads. <li>Miscellaneous micro-optimizations result in 22.3% more work for the same number of CPU cycles relative to the previous release. SQLite now runs twice as fast as [version 3.8.0] and three times as fast as [version 3.3.9]. (Measured using [http://valgrind.org/docs/manual/cg-manual.html|cachegrind] on the [https://www.sqlite.org/src/artifact/83f6b3318f7ee|speedtest1.c] workload on Ubuntu 14.04 x64 with gcc 4.8.2 and -Os. Your performance may vary.) <li>Added the [sqlite3_result_zeroblob64()] and [sqlite3_bind_zeroblob64()] interfaces. <p><b>Important bug fixes:</b> <li>Fix [CREATE TABLE AS] so that columns of type TEXT never end up holding an INT value. Ticket [https://www.sqlite.org/src/info/f2ad7de056ab1dc9200|f2ad7de056ab1dc9200] |
︙ | ︙ | |||
1537 1538 1539 1540 1541 1542 1543 | chng {2014-11-18 (3.8.7.2)} { <li>Enhance the [ROLLBACK] command so that pending queries are allowed to continue as long as the schema is unchanged. Formerly, a ROLLBACK would cause all pending queries to fail with an [SQLITE_ABORT] or [SQLITE_ABORT_ROLLBACK] error. That error is still returned if the ROLLBACK modifies the schema. <li>Bug fix: Make sure that NULL results from OP_Column are fully and completely NULL and do not have the MEM_Ephem bit set. | | | | 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 | chng {2014-11-18 (3.8.7.2)} { <li>Enhance the [ROLLBACK] command so that pending queries are allowed to continue as long as the schema is unchanged. Formerly, a ROLLBACK would cause all pending queries to fail with an [SQLITE_ABORT] or [SQLITE_ABORT_ROLLBACK] error. That error is still returned if the ROLLBACK modifies the schema. <li>Bug fix: Make sure that NULL results from OP_Column are fully and completely NULL and do not have the MEM_Ephem bit set. Ticket [https://www.sqlite.org/src/info/094d39a4c95ee4|094d39a4c95ee4]. <li>Bug fix: The %c format in sqlite3_mprintf() is able to handle precisions greater than 70. <li>Bug fix: Do not automatically remove the DISTINCT keyword from a SELECT that forms the right-hand side of an IN operator since it is necessary if the SELECT also contains a LIMIT. Ticket [https://www.sqlite.org/src/info/db87229497|db87229497]. <li>SQLITE_SOURCE_ID: "2014-11-18 20:57:56 2ab564bf9655b7c7b97ab85cafc8a48329b27f93" <li>SHA1 for sqlite3.c: b2a68d5783f48dba6a8cb50d8bf69b238c5ec53a } chng {2014-10-29 (3.8.7.1)} { <li>In [PRAGMA journal_mode=TRUNCATE] mode, call fsync() immediately after truncating |
︙ | ︙ | |||
1569 1570 1571 1572 1573 1574 1575 | chng {2014-10-17 (3.8.7)} { <p><b>Performance Enhancements:</b> <li>Many micro-optimizations result in 20.3% more work for the same number of CPU cycles relative to the previous release. The cumulative performance increase since [version 3.8.0] is 61%. (Measured using [http://valgrind.org/docs/manual/cg-manual.html|cachegrind] on the | | | 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 | chng {2014-10-17 (3.8.7)} { <p><b>Performance Enhancements:</b> <li>Many micro-optimizations result in 20.3% more work for the same number of CPU cycles relative to the previous release. The cumulative performance increase since [version 3.8.0] is 61%. (Measured using [http://valgrind.org/docs/manual/cg-manual.html|cachegrind] on the [https://www.sqlite.org/src/artifact/83f6b3318f7ee|speedtest1.c] workload on Ubuntu 13.10 x64 with gcc 4.8.1 and -Os. Your performance may vary.) <li>The sorter can use auxiliary helper threads to increase real-time response. This feature is off by default and may be enabled using the [PRAGMA threads] command or the [SQLITE_DEFAULT_WORKER_THREADS] compile-time option. <li>Enhance the [skip-scan] optimization so that it is able to skip index terms that occur in the middle of the index, not just as the left-hand side of the index. |
︙ | ︙ | |||
1594 1595 1596 1597 1598 1599 1600 | [sqlite3_result_text64()]. <li>Added the new interface [sqlite3_msize()] that returns the size of a memory allocation obtained from [sqlite3_malloc64()] and its variants. <li>Added the [SQLITE_LIMIT_WORKER_THREADS] option to [sqlite3_limit()] and [PRAGMA threads] command for configuring the number of available worker threads. <li>The [spellfix1] extension allows the application to optionally specify the rowid for each INSERT. | | | | | | | 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 | [sqlite3_result_text64()]. <li>Added the new interface [sqlite3_msize()] that returns the size of a memory allocation obtained from [sqlite3_malloc64()] and its variants. <li>Added the [SQLITE_LIMIT_WORKER_THREADS] option to [sqlite3_limit()] and [PRAGMA threads] command for configuring the number of available worker threads. <li>The [spellfix1] extension allows the application to optionally specify the rowid for each INSERT. <li>Added the [https://www.sqlite.org/src/doc/trunk/ext/userauth/user-auth.txt|User Authentication] extension. <p><b>Bug Fixes:</b> <li>Fix a bug in the [partial index] implementation that might result in an incorrect answer if a partial index is used in a subquery or in a [view]. Ticket [https://www.sqlite.org/src/info/98d973b8f5|98d973b8f5]. <li>Fix a query planner bug that might cause a table to be scanned in the wrong direction (thus reversing the order of output) when a DESC index is used to implement the ORDER BY clause on a query that has an identical GROUP BY clause. Ticket [https://www.sqlite.org/src/info/ba7cbfaedc7e6|ba7cbfaedc7e6]. <li>Fix a bug in [sqlite3_trace()] that was causing it to sometimes fail to print an SQL statement if that statement needed to be re-prepared. Ticket [https://www.sqlite.org/src/info/11d5aa455e0d98f3c1e6a08|11d5aa455e0d98f3c1e6a08] <li>Fix a faulty assert() statement. Ticket [https://www.sqlite.org/src/info/369d57fb8e5ccdff06f1|369d57fb8e5ccdff06f1] <p><b>Test, Debug, and Analysis Changes:</b> <li>Show ASCII-art abstract syntax tree diagrams using the ".selecttrace" and ".wheretrace" commands in the [command-line shell] when compiled with [SQLITE_DEBUG], SQLITE_ENABLE_SELECTTRACE, and SQLITE_ENABLE_WHERETRACE. Also provide the sqlite3TreeViewExpr() and sqlite3TreeViewSelect() entry points that can be invoked from with the debugger to show the parse tree when stopped at a breakpoint. |
︙ | ︙ | |||
1639 1640 1641 1642 1643 1644 1645 | error from 1 second to 10 seconds. <li>Added the [likely(X)] SQL function. <li>The [unicode61] tokenizer is now included in [FTS4] by default. <li>Trigger automatic reprepares on all prepared statements when [ANALYZE] is run. <li>Added a new [loadable extension] source code file to the source tree: | | | 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 | error from 1 second to 10 seconds. <li>Added the [likely(X)] SQL function. <li>The [unicode61] tokenizer is now included in [FTS4] by default. <li>Trigger automatic reprepares on all prepared statements when [ANALYZE] is run. <li>Added a new [loadable extension] source code file to the source tree: [https://www.sqlite.org/src/finfo?name=ext/misc/fileio.c|fileio.c] <li>Add extension functions [file I/O functions|readfile(X) and writefile(X,Y)] (using code copy/pasted from fileio.c in the previous bullet) to the [command-line shell]. <li>Added the [.fullschema] dot-command to the [command-line shell]. <p><b>Performance Enhancements:</b> <li>Deactivate the [DISTINCT] keyword on subqueries on the right-hand side of the [IN operator]. |
︙ | ︙ | |||
1661 1662 1663 1664 1665 1666 1667 | <li>Ensure that the query planner never tries to use a self-made transient index in place of a schema-defined index. <li>Other minor tweaks to improve the quality of [VDBE] code. <p><b>Bug Fixes:</b> <li>Fix a bug in [CREATE INDEX|CREATE UNIQUE INDEX], introduced when [WITHOUT ROWID] support added in version 3.8.2, that allows a non-unique NOT NULL column to be given a UNIQUE index. | | | | | | | 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 | <li>Ensure that the query planner never tries to use a self-made transient index in place of a schema-defined index. <li>Other minor tweaks to improve the quality of [VDBE] code. <p><b>Bug Fixes:</b> <li>Fix a bug in [CREATE INDEX|CREATE UNIQUE INDEX], introduced when [WITHOUT ROWID] support added in version 3.8.2, that allows a non-unique NOT NULL column to be given a UNIQUE index. Ticket [https://www.sqlite.org/src/info/9a6daf340df99ba93c|9a6daf340df99ba93c] <li>Fix a bug in [R-Tree extension], introduced in the previous release, that can cause an incorrect results for queries that use the rowid of the R-Tree on the left-hand side of an [IN operator]. Ticket [https://www.sqlite.org/src/info/d2889096e7bdeac6|d2889096e7bdeac6]. <li>Fix the [sqlite3_stmt_busy()] interface so that it gives the correct answer for [ROLLBACK] statements that have been stepped but never reset. <li>Fix a bug in that would cause a null pointer to be dereferenced if a column with a DEFAULT that is an aggregate function tried to usee its DEFAULT. Ticket [https://www.sqlite.org/src/info/3a88d85f36704eebe1|3a88d85f36704eebe1] <li>CSV output from the [command-line shell] now always uses CRNL for the row separator and avoids inserting CR in front of NLs contained in data. <li>Fix a [column affinity] problem with the [IN operator]. Ticket [https://www.sqlite.org/src/info/9a8b09f8e6|9a8b09f8e6]. <li>Fix the [ANALYZE] command so that it adds correct samples for [WITHOUT ROWID] tables in the [sqlite_stat4] table. Ticket [https://www.sqlite.org/src/info/b2fa5424e6fcb15|b2fa5424e6fcb15]. <li>SQLITE_SOURCE_ID: "2014-08-15 11:46:33 9491ba7d738528f168657adb43a198238abde19e" <li>SHA1 for sqlite3.c: 72c64f05cd9babb9c0f9b3c82536d83be7804b1c } chng {2014-06-04 (3.8.5)} { <li>Added support for [partial sorting by index]. |
︙ | ︙ | |||
1706 1707 1708 1709 1710 1711 1712 | Similarly optimize "x NOT IN (?)" <li>Add the ".system" and ".once" commands to the [command-line shell]. <li>Added the [SQLITE_IOCAP_IMMUTABLE] bit to the set of bits that can be returned by the xDeviceCharacteristics method of a [VFS]. <li>Added the [SQLITE_TESTCTRL_BYTEORDER] test control. <p><b>Bug Fixes:</b> <li>OFFSET clause ignored on queries without a FROM clause. | | | | | | | | | | | | | 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 | Similarly optimize "x NOT IN (?)" <li>Add the ".system" and ".once" commands to the [command-line shell]. <li>Added the [SQLITE_IOCAP_IMMUTABLE] bit to the set of bits that can be returned by the xDeviceCharacteristics method of a [VFS]. <li>Added the [SQLITE_TESTCTRL_BYTEORDER] test control. <p><b>Bug Fixes:</b> <li>OFFSET clause ignored on queries without a FROM clause. Ticket [https://www.sqlite.org/src/info/07d6a0453d | 07d6a0453d] <li>Assertion fault on queries involving expressions of the form "x IN (?)". Ticket [https://www.sqlite.org/src/info/e39d032577|e39d032577]. <li>Incorrect column datatype reported. Ticket [https://www.sqlite.org/src/info/a8a0d2996a | a8a0d2996a] <li>Duplicate row returned on a query against a table with more than 16 indices, each on a separate column, and all used via OR-connected constraints. Ticket [https://www.sqlite.org/src/info/10fb063b11 | 10fb063b11] <li>Partial index causes assertion fault on UPDATE OR REPLACE. Ticket [https://www.sqlite.org/src/info/2ea3e9fe63 | 2ea3e9fe63] <li>Crash when calling undocumented SQL function sqlite_rename_parent() with NULL parameters. Ticket [https://www.sqlite.org/src/info/264b970c4379fd | 264b970c43] <li>ORDER BY ignored if the query has an identical GROUP BY. Ticket [https://www.sqlite.org/src/info/b75a9ca6b0499 | b75a9ca6b0] <li>The group_concat(x,'') SQL function returns NULL instead of an empty string when all inputs are empty strings. Ticket [https://www.sqlite.org/src/info/55746f9e65f85 | 55746f9e65] <li>Fix a bug in the VDBE code generator that caused crashes when doing an INSERT INTO ... SELECT statement where the number of columns being inserted is larger than the number of columns in the destination table. Ticket [https://www.sqlite.org/src/info/e9654505cfda9 | e9654505cfd] <li>Fix a problem in CSV import in the [command-line shell] where if the leftmost field of the first row in the CSV file was both zero bytes in size and unquoted no data would be imported. <li>Fix a problem in FTS4 where the left-most column that contained the [FTS4 notindexed option | notindexed column] name as a prefix was not indexed rather than the column whose name matched exactly. <li>Fix the [sqlite3_db_readonly()] interface so that it returns true if the database is read-only due to the file format write version number being too large. <li>SQLITE_SOURCE_ID: "2014-06-04 14:06:34 b1ed4f2a34ba66c29b130f8d13e9092758019212" <li>SHA1 for sqlite3.c: 7bc194957238c61b1a47f301270286be5bc5208c } chng {2014-04-03 (3.8.4.3)} { <li>Add a [https://www.sqlite.org/src/fdiff?sbs=1&v1=7d539cedb1c&v2=ebad891b7494d&smhdr|one-character fix] for a problem that might cause incorrect query results on a query that mixes DISTINCT, GROUP BY in a subquery, and ORDER BY. [https://www.sqlite.org/src/info/98825a79ce1456863|Ticket 98825a79ce14]. <li>SQLITE_SOURCE_ID: "2014-04-03 16:53:12 a611fa96c4a848614efe899130359c9f6fb889c3" <li>SHA1 for sqlite3.c: 310a1faeb9332a3cd8d1f53b4a2e055abf537bdc } chng {2014-03-26 (3.8.4.2)} { <li>Fix a potential buffer overread that could result when trying to search a corrupt database file. |
︙ | ︙ | |||
1786 1787 1788 1789 1790 1791 1792 | <li>Change the datatype of SrcList.nSrc from type u8 to type int to work around an issue in the C compiler on AIX. <li>Get extension loading working on Cygwin. <li>Bug fix: Fix the [char()] SQL function so that it returns an empty string rather than an "out of memory" error when called with zero arguments. <li>Bug fix: DISTINCT now recognizes that a [zeroblob] and a blob of all 0x00 bytes are the same thing. | | | | | | | | | 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 | <li>Change the datatype of SrcList.nSrc from type u8 to type int to work around an issue in the C compiler on AIX. <li>Get extension loading working on Cygwin. <li>Bug fix: Fix the [char()] SQL function so that it returns an empty string rather than an "out of memory" error when called with zero arguments. <li>Bug fix: DISTINCT now recognizes that a [zeroblob] and a blob of all 0x00 bytes are the same thing. [https://www.sqlite.org/src/info/fccbde530a | Ticket [fccbde530a]] <li>Bug fix: Compute the correct answer for queries that contain an IS NOT NULL term in the WHERE clause and also contain an OR term in the WHERE clause and are compiled with [SQLITE_ENABLE_STAT4]. [https://www.sqlite.org/src/info/4c86b126f2 | Ticket [4c86b126f2]] <li>Bug fix: Make sure "rowid" columns are correctly resolved in joins between normal tables and WITHOUT ROWID tables. [https://www.sqlite.org/src/info/c34d0557f7 | Ticket [c34d0557f7]] <li>Bug fix: Make sure the same temporary registers are not used in concurrent co-routines used to implement compound SELECT statements containing ORDER BY clauses, as such use can lead to incorrect answers. [https://www.sqlite.org/src/info/8c63ff0eca | Ticket [8c63ff0eca]] <li>Bug fix: Ensure that "ORDER BY random()" clauses do not get optimized out. [https://www.sqlite.org/src/info/65bdeb9739 | Ticket [65bdeb9739]] <li>Bug fix: Repair a name-resolution error that can occur in sub-select statements contained within a TRIGGER. [https://www.sqlite.org/src/info/4ef7e3cfca | Ticket [4ef7e3cfca]] <li>Bug fix: Fix column default values expressions of the form "DEFAULT(-(-9223372036854775808))" so that they work correctly, initializing the column to a floating point value approximately equal to +9223372036854775808.0. <li>SQLITE_SOURCE_ID: "2014-03-10 12:20:37 530a1ee7dc2435f80960ce4710a3c2d2bfaaccc5" <li>SHA1 for sqlite3.c: b0c22e5f15f5ba2afd017ecd990ea507918afe1c } chng {2014-02-11 (3.8.3.1)} { <li>Fix a bug (ticket [https://www.sqlite.org/src/info/4c86b126f2|4c86b126f2]) that causes rows to go missing on some queries with OR clauses and IS NOT NULL operators in the WHERE clause, when the [SQLITE_ENABLE_STAT3] or [SQLITE_ENABLE_STAT4] compile-time options are used. <li>Fix a harmless compiler warning that was causing problems for VS2013. <li>SQLITE_SOURCE_ID: "2014-02-11 14:52:19 ea3317a4803d71d88183b29f1d3086f46d68a00e" <li>SHA1 for sqlite3.c: 990004ef2d0eec6a339e4caa562423897fe02bf0 } |
︙ | ︙ | |||
1920 1921 1922 1923 1924 1925 1926 | <li>The directory used to hold temporary files on unix can now be set using the SQLITE_TMPDIR environment variable, which takes precedence over the TMPDIR environment variable. The [sqlite3_temp_directory] global variable still has higher precedence than both environment variables, however. <li>Added the [PRAGMA stats] statement. <li><b>Bug fix:</b> Return the correct answer for "SELECT count(*) FROM table" even if there is a [partial index] on the table. Ticket | | | 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 | <li>The directory used to hold temporary files on unix can now be set using the SQLITE_TMPDIR environment variable, which takes precedence over the TMPDIR environment variable. The [sqlite3_temp_directory] global variable still has higher precedence than both environment variables, however. <li>Added the [PRAGMA stats] statement. <li><b>Bug fix:</b> Return the correct answer for "SELECT count(*) FROM table" even if there is a [partial index] on the table. Ticket [https://www.sqlite.org/src/info/a5c8ed66ca|a5c8ed66ca]. <li>SQLITE_SOURCE_ID: "2013-10-17 12:57:35 c78be6d786c19073b3a6730dfe3fb1be54f5657a" <li>SHA1 for sqlite3.c: 0a54d76566728c2ba96292a49b138e4f69a7c391 } chng {2013-09-03 (3.8.0.2)} { |
︙ | ︙ | |||
2049 2050 2051 2052 2053 2054 2055 | <li>Discontinue the use of posix_fallocate() on unix, as it does not work on all filesystems. <li>Improved tracing and debugging facilities in the Windows [VFS]. <li>Bug fix: Fix a potential <b>database corruption bug</b> in [shared cache mode] when one [database connection] is closed while another is in the middle of a write transaction. | | | | | | | | | | | | | | | 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 | <li>Discontinue the use of posix_fallocate() on unix, as it does not work on all filesystems. <li>Improved tracing and debugging facilities in the Windows [VFS]. <li>Bug fix: Fix a potential <b>database corruption bug</b> in [shared cache mode] when one [database connection] is closed while another is in the middle of a write transaction. Ticket [https://www.sqlite.org/src/info/e636a050b7 | e636a050b7] <li>Bug fix: Only consider AS names from the result set as candidates for resolving identifiers in the WHERE clause if there are no other matches. In the ORDER BY clause, AS names take priority over any column names. Ticket [https://www.sqlite.org/src/info/2500cdb9be05 | 2500cdb9be05] <li>Bug fix: Do not allow a virtual table to cancel the ORDER BY clause unless all outer loops are guaranteed to return no more than one row result. Ticket [https://www.sqlite.org/src/info/ba82a4a41eac1 | ba82a4a41eac1]. <li>Bug fix: Do not suppress the ORDER BY clause on a virtual table query if an IN constraint is used. Ticket [https://www.sqlite.org/src/info/f69b96e3076e | f69b96e3076e]. <li>Bug fix: The [command-line shell] gives an exit code of 0 when terminated using the ".quit" command. <li>Bug fix: Make sure [PRAGMA] statements appear in [sqlite3_trace()] output. <li>Bug fix: When a [compound query] that uses an ORDER BY clause with a [COLLATE operator], make sure that the sorting occurs according to the specified collation and that the comparisons associate with the compound query use the native collation. Ticket [https://www.sqlite.org/src/info/6709574d2a8d8 | 6709574d2a8d8]. <li>Bug fix: Makes sure the [sqlite3_set_authorizer | authorizer] callback gets a valid pointer to the string "ROWID" for the column-name parameter when doing an [UPDATE] that changes the rowid. Ticket [https://www.sqlite.org/src/info/0eb70d77cb05bb2272 | 0eb70d77cb05bb2272] <li>Bug fix: Do not move WHERE clause terms inside OR expressions that are contained within an ON clause of a LEFT JOIN. Ticket [https://www.sqlite.org/src/info/f2369304e4 | f2369304e4] <li>Bug fix: Make sure an error is always reported when attempting to preform an operation that requires a [collating sequence] that is missing. Ticket [https://www.sqlite.org/src/info/0fc59f908b | 0fc59f908b] <li>SQLITE_SOURCE_ID: "2013-05-20 00:56:22 118a3b35693b134d56ebd780123b7fd6f1497668" <li>SHA1 for sqlite3.c: 246987605d0503c700a08b9ee99a6b5d67454aab } chng {2013-04-12 (3.7.16.2)} { <li>Fix a bug (present since version 3.7.13) that could result in database corruption on windows if two or more processes try to access the same database file at the same time and immediately after third process crashed in the middle of committing to that same file. See ticket [https://www.sqlite.org/src/info/7ff3120e4f | 7ff3120e4f] for further information. <li>SQLITE_SOURCE_ID: "2013-04-12 11:52:43 cbea02d93865ce0e06789db95fd9168ebac970c7" <li>SHA1 for sqlite3.c: d466b54789dff4fb0238b9232e74896deaefab94 } {inadditionto 2 inadditionto 1} chng {2013-03-29 (3.7.16.1)} { <li>Fix for a bug in the ORDER BY optimizer that was introduced in [version 3.7.15] which would sometimes optimize out the sorting step when in fact the sort was required. Ticket [https://www.sqlite.org/src/info/a179fe7465 | a179fe7465] <li>Fix a long-standing bug in the [CAST expression] that would recognize UTF16 characters as digits even if their most-significant-byte was not zero. Ticket [https://www.sqlite.org/src/info/689137afb6da41 | 689137afb6da41]. <li>Fix a bug in the NEAR operator of [FTS3] when applied to subfields. Ticket [https://www.sqlite.org/src/info/38b1ae018f | 38b1ae018f]. <li>Fix a long-standing bug in the storage engine that would (very rarely) cause a spurious report of an SQLITE_CORRUPT error but which was otherwise harmless. Ticket [https://www.sqlite.org/src/info/6bfb98dfc0c | 6bfb98dfc0c]. <li>The SQLITE_OMIT_MERGE_SORT option has been removed. The merge sorter is now a required component of SQLite. <li>Fixed lots of spelling errors in the source-code comments <li>SQLITE_SOURCE_ID: "2013-03-29 13:44:34 527231bc67285f01fb18d4451b28f61da3c4e39d" <li>SHA1 for sqlite3.c: 7a91ceceac9bcf47ceb8219126276e5518f7ff5a } {inadditionto 1} |
︙ | ︙ | |||
2163 2164 2165 2166 2167 2168 2169 | <li>Enhance the [spellfix1] extension so that the edit distance cost table can be changed at runtime by inserting a string like 'edit_cost_table=TABLE' into the "command" field. <li>Bug fix: repair a long-standing problem that could cause incorrect query results in a 3-way or larger join that compared INTEGER fields against TEXT fields in two or more places. | | | | | 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 | <li>Enhance the [spellfix1] extension so that the edit distance cost table can be changed at runtime by inserting a string like 'edit_cost_table=TABLE' into the "command" field. <li>Bug fix: repair a long-standing problem that could cause incorrect query results in a 3-way or larger join that compared INTEGER fields against TEXT fields in two or more places. Ticket [https://www.sqlite.org/src/info/fc7bd6358f | fc7bd6358f] <li>Bug fix: Issue an error message if the 16-bit reference counter on a view overflows due to an overly complex query. <li>Bug fix: Avoid leaking memory on LIMIT and OFFSET clauses in deeply nested UNION ALL queries. <li>Bug fix: Make sure the schema is up-to-date prior to running pragmas table_info, index_list, index_info, and foreign_key_list. <li>SQLITE_SOURCE_ID: "2013-03-18 11:39:23 66d5f2b76750f3520eb7a495f6247206758f5b90" <li>SHA1 for sqlite3.c: 7308ab891ca1b2ebc596025cfe4dc36f1ee89cf6 } chng {2013-01-09 (3.7.15.2)} { <li>Fix a bug, introduced in [version 3.7.15], that causes an ORDER BY clause to be optimized out of a three-way join when the ORDER BY is actually required. Ticket [https://www.sqlite.org/src/info/598f5f7596b055 | 598f5f7596b055] <li>SQLITE_SOURCE_ID: "2013-01-09 11:53:05 c0e09560d26f0a6456be9dd3447f5311eb4f238f" <li>SHA1 for sqlite3.c: 5741f47d1bc38aa0a8c38f09e60a5fe0031f272d } chng {2012-12-19 (3.7.15.1)} { <li>Fix a bug, introduced in [version 3.7.15], that causes a segfault if the AS name of a result column of a SELECT statement is used as a logical term in the WHERE clause. Ticket [https://www.sqlite.org/src/info/a7b7803e8d1e869 | a7b7803e8d1e869]. <li>SQLITE_SOURCE_ID: "2012-12-19 20:39:10 6b85b767d0ff7975146156a99ad673f2c1a23318" <li>SHA1 for sqlite3.c: bbbaa68061e925bd4d7d18d7e1270935c5f7e39a } chng {2012-12-12 (3.7.15)} { |
︙ | ︙ | |||
2312 2313 2314 2315 2316 2317 2318 | <li>SQLITE_SOURCE_ID: "2012-06-11 02:05:22 f5b5a13f7394dc143aa136f1d4faba6839eaa6dc" <li>SHA1 for sqlite3.c: ff0a771d6252545740ba9685e312b0e3bb6a641b } chng {2012-05-22 (3.7.12.1)} { <li>Fix a bug | | | 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 | <li>SQLITE_SOURCE_ID: "2012-06-11 02:05:22 f5b5a13f7394dc143aa136f1d4faba6839eaa6dc" <li>SHA1 for sqlite3.c: ff0a771d6252545740ba9685e312b0e3bb6a641b } chng {2012-05-22 (3.7.12.1)} { <li>Fix a bug [https://www.sqlite.org/src/info/c2ad16f997ee9c | (ticket c2ad16f997)] in the 3.7.12 release that can cause a segfault for certain obscure nested aggregate queries. <li>Fix various other minor test script problems. <li>SQLITE_SOURCE_ID: "2012-05-22 02:45:53 6d326d44fd1d626aae0e8456e5fa2049f1ce0789" <li>SHA1 for sqlite3.c: d494e8d81607f0515d4f386156fb0fd86d5ba7df } |
︙ | ︙ | |||
2352 2353 2354 2355 2356 2357 2358 | <li>Improved optimization of aggregate subqueries contained within an aggregate query. <li>Bug fix: Fix the [RELEASE] command so that it does not cancel pending queries. This repairs a problem introduced in 3.7.11. <li>Bug fix: Do not discard the DISTINCT as superfluous unless a subset of the result set is subject to a UNIQUE constraint <em>and</em> it none of the columns in that subset can be NULL. | | | | 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 | <li>Improved optimization of aggregate subqueries contained within an aggregate query. <li>Bug fix: Fix the [RELEASE] command so that it does not cancel pending queries. This repairs a problem introduced in 3.7.11. <li>Bug fix: Do not discard the DISTINCT as superfluous unless a subset of the result set is subject to a UNIQUE constraint <em>and</em> it none of the columns in that subset can be NULL. Ticket [https://www.sqlite.org/src/info/385a5b56b9 | 385a5b56b9]. <li>Bug fix: Do not optimize away an ORDER BY clause that has the same terms as a UNIQUE index unless those terms are also NOT NULL. Ticket [https://www.sqlite.org/src/info/2a5629202f | 2a5629202f]. <li>SQLITE_SOURCE_ID: "2012-05-14 01:41:23 8654aa9540fe9fd210899d83d17f3f407096c004" <li>SHA1 for sqlite3.c: 57e2104a0f7b3f528e7f6b7a8e553e2357ccd2e1 } chng {2012-03-20 (3.7.11)} { |
︙ | ︙ | |||
2382 2383 2384 2385 2386 2387 2388 | <li>Added support for the [FTS4 languageid option]. <li>Documented support for the [FTS4 content option]. This feature has actually been in the code since [version 3.7.9] but is only now considered to be officially supported. <li>Pending statements no longer block [ROLLBACK]. Instead, the pending statement will return SQLITE_ABORT upon next access after the ROLLBACK. <li>Improvements to the handling of CSV inputs in the [command-line shell] | | | 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 | <li>Added support for the [FTS4 languageid option]. <li>Documented support for the [FTS4 content option]. This feature has actually been in the code since [version 3.7.9] but is only now considered to be officially supported. <li>Pending statements no longer block [ROLLBACK]. Instead, the pending statement will return SQLITE_ABORT upon next access after the ROLLBACK. <li>Improvements to the handling of CSV inputs in the [command-line shell] <li>Fix a [https://www.sqlite.org/src/info/b7c8682cc1|bug] introduced in [version 3.7.10] that might cause a LEFT JOIN to be incorrectly converted into an INNER JOIN if the WHERE clause indexable terms connected by OR. <li>SQLITE_SOURCE_ID: "2012-03-20 11:35:50 00bb9c9ce4f465e6ac321ced2a9d0062dc364669" <li>SHA1 for sqlite3.c: d460d7eda3a9dccd291aed2a9fda868b9b120a10 |
︙ | ︙ | |||
2446 2447 2448 2449 2450 2451 2452 | [SQLITE_ENABLE_TREE_EXPLAIN] compile-time option to enable the [command-line shell] to display ASCII-art parse trees of SQL statements that it processes, for debugging and analysis. <li><b>Bug fix:</b> Add an additional xSync when restarting a WAL in order to prevent an exceedingly unlikely but theoretically possible database corruption following power-loss. | | | | | 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 | [SQLITE_ENABLE_TREE_EXPLAIN] compile-time option to enable the [command-line shell] to display ASCII-art parse trees of SQL statements that it processes, for debugging and analysis. <li><b>Bug fix:</b> Add an additional xSync when restarting a WAL in order to prevent an exceedingly unlikely but theoretically possible database corruption following power-loss. Ticket [https://www.sqlite.org/src/info/ff5be73dee | ff5be73dee]. <li><b>Bug fix:</b> Change the VDBE so that all registers are initialized to Invalid instead of NULL. Ticket [https://www.sqlite.org/src/info/7bbfb7d442 | 7bbfb7d442] <li><b>Bug fix:</b> Fix problems that can result from 32-bit integer overflow. Ticket [https://www.sqlite.org/src/info/ac0ff496b7e2 | ac00f496b7e2] <li>SQLITE_SOURCE_ID: "2012-01-16 13:28:40 ebd01a8deffb5024a5d7494eef800d2366d97204" <li>SHA1 for sqlite3.c: 6497cbbaad47220bd41e2e4216c54706e7ae95d4 } chng {2011-11-01 (3.7.9)} { <li>If a search token (on the right-hand side of the MATCH operator) in |
︙ | ︙ | |||
2524 2525 2526 2527 2528 2529 2530 | indices in a WHERE clause. <li> SQLITE_SOURCE_ID: "2011-09-19 14:49:19 3e0da808d2f5b4d12046e05980ca04578f581177" <li> SHA1 for sqlite3.c: bfcd74a655636b592c5dba6d0d5729c0f8e3b4de } chng {2011-06-28 (3.7.7.1)} { | | | 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 | indices in a WHERE clause. <li> SQLITE_SOURCE_ID: "2011-09-19 14:49:19 3e0da808d2f5b4d12046e05980ca04578f581177" <li> SHA1 for sqlite3.c: bfcd74a655636b592c5dba6d0d5729c0f8e3b4de } chng {2011-06-28 (3.7.7.1)} { <li> Fix [https://www.sqlite.org/src/info/25ee812710 | a bug] causing [PRAGMA case_sensitive_like] statements compiled using sqlite3_prepare() to fail with an [SQLITE_SCHEMA] error. <li> SQLITE_SOURCE_ID: "2011-06-28 17:39:05 af0d91adf497f5f36ec3813f04235a6e195a605f" <li> SHA1 for sqlite3.c: d47594b8a02f6cf58e91fb673e96cb1b397aace0 } |
︙ | ︙ | |||
2616 2617 2618 2619 2620 2621 2622 | [SQLITE_DBSTATUS_LOOKASIDE_MISS_FULL] options for the [sqlite3_db_status()] interface. <li> Added the [SQLITE_OMIT_AUTORESET] compile-time option. <li> Added the [SQLITE_DEFAULT_FOREIGN_KEYS] compile-time option. <li> Updates to [sqlite3_stmt_readonly()] so that its result is well-defined for all prepared statements and so that it works with [VACUUM]. <li> Added the "-heap" option to the [command-line shell] | | | 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 | [SQLITE_DBSTATUS_LOOKASIDE_MISS_FULL] options for the [sqlite3_db_status()] interface. <li> Added the [SQLITE_OMIT_AUTORESET] compile-time option. <li> Added the [SQLITE_DEFAULT_FOREIGN_KEYS] compile-time option. <li> Updates to [sqlite3_stmt_readonly()] so that its result is well-defined for all prepared statements and so that it works with [VACUUM]. <li> Added the "-heap" option to the [command-line shell] <li> Fix [https://www.sqlite.org/src/info/5d863f876e | a bug] involving frequent changes in and out of WAL mode and VACUUM that could (in theory) cause database corruption. <li> Enhance the [sqlite3_trace()] mechanism so that nested SQL statements such as might be generated by virtual tables are shown but are shown in comments and without parameter expansion. This greatly improves tracing output when using the FTS3/4 and/or RTREE virtual tables. |
︙ | ︙ | |||
2653 2654 2655 2656 2657 2658 2659 | to the FTS [matchinfo()] function. <li> Added the test_superlock.c module which provides example code for obtaining an exclusive lock to a rollback or WAL database. <li> Added the test_multiplex.c module which provides an example VFS that provides multiplexing (sharding) of a DB, splitting it over multiple files of fixed size. | | | 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 | to the FTS [matchinfo()] function. <li> Added the test_superlock.c module which provides example code for obtaining an exclusive lock to a rollback or WAL database. <li> Added the test_multiplex.c module which provides an example VFS that provides multiplexing (sharding) of a DB, splitting it over multiple files of fixed size. <li> A [https://www.sqlite.org/src/info/80ba201079 | very obscure bug] associated with the [or optimization] was fixed. } chng {2010-10-08 (3.7.3)} { <li> Added the [sqlite3_create_function_v2()] interface that includes a destructor callback. <li> Added support for [custom r-tree queries] using application-supplied |
︙ | ︙ | |||
2686 2687 2688 2689 2690 2691 2692 | the VDBE provides hints to the B-Tree layer letting the B-Tree layer know when it is safe to use hashing instead of B-Trees for transient tables. <li> Miscellaneous documentation enhancements. } chng {2010-08-24 (3.7.2)} { | | | 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 | the VDBE provides hints to the B-Tree layer letting the B-Tree layer know when it is safe to use hashing instead of B-Trees for transient tables. <li> Miscellaneous documentation enhancements. } chng {2010-08-24 (3.7.2)} { <li> Fix an <a href="https://www.sqlite.org/src/info/5e10420e8d"> old and very obscure bug</a> that can lead to corruption of the database [free-page list] when [incremental_vacuum] is used. } chng {2010-08-23 (3.7.1)} { <li> Added new commands [SQLITE_DBSTATUS_SCHEMA_USED] and [SQLITE_DBSTATUS_STMT_USED] to the [sqlite3_db_status()] interface, in |
︙ | ︙ | |||
2713 2714 2715 2716 2717 2718 2719 | <li> The SQLITE_MAX_PAGE_SIZE compile-time option is now silently ignored. The maximum page size is hard-coded at 65536 bytes. } chng {2010-08-04 (3.7.0.1)} { <li> Fix a potential database corruption bug that can occur if version 3.7.0 and version 3.6.23.1 alternately write to the same database file. | | | 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 | <li> The SQLITE_MAX_PAGE_SIZE compile-time option is now silently ignored. The maximum page size is hard-coded at 65536 bytes. } chng {2010-08-04 (3.7.0.1)} { <li> Fix a potential database corruption bug that can occur if version 3.7.0 and version 3.6.23.1 alternately write to the same database file. <a href="https://www.sqlite.org/src/info/51ae9cad317a1"> Ticket [51ae9cad317a1]</a> <li> Fix a performance regression related to the query planner enhancements of version 3.7.0. } chng {2010-07-21 (3.7.0)} { <li> Added support for [WAL | write-ahead logging]. |
︙ | ︙ | |||
2801 2802 2803 2804 2805 2806 2807 | re-compiled when a binding on the RHS of a LIKE operator changes or when any range constraint changes under [SQLITE_ENABLE_STAT2]. <li>Various minor bug fixes and documentation enhancements. } chng {2009-10-30 (3.6.16.1)} { <li>A small patch to version 3.6.16 to fix | | | | | | 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 | re-compiled when a binding on the RHS of a LIKE operator changes or when any range constraint changes under [SQLITE_ENABLE_STAT2]. <li>Various minor bug fixes and documentation enhancements. } chng {2009-10-30 (3.6.16.1)} { <li>A small patch to version 3.6.16 to fix <a href="https://www.sqlite.org/src/info/6b00e0a34c">the OP_If bug</a>. } chng {2009-10-14 (3.6.19)} { <li>Added support for [foreign key constraints]. Foreign key constraints are disabled by default. Use the [foreign_keys pragma] to turn them on. <li>Generalized the IS and IS NOT operators to take arbitrary expressions on their right-hand side. <li>The [TCL Interface] has been enhanced to use the [https://www.tcl.tk/cgi-bin/tct/tip/322.html | Non-Recursive Engine (NRE)] interface to the TCL interpreter when linked against TCL 8.6 or later. <li>Fix a bug introduced in 3.6.18 that can lead to a segfault when an attempt is made to write on a read-only database. } chng {2009-09-11 (3.6.18)} { <li>Versioning of the SQLite source code has transitioned from CVS to [https://www.fossil-scm.org/ | Fossil]. <li>Query planner enhancements. <li>The [SQLITE_ENABLE_STAT2] compile-time option causes the [ANALYZE] command to collect a small histogram of each index, to help SQLite better select among competing range query indices. <li>Recursive triggers can be enabled using the [PRAGMA recursive_triggers] statement. <li>Delete triggers fire when rows are removed due to a [ON CONFLICT | REPLACE conflict resolution]. This feature is only enabled when recursive triggers are enabled. <li>Added the [SQLITE_OPEN_SHAREDCACHE] and [SQLITE_OPEN_PRIVATECACHE] flags for [sqlite3_open_v2()] used to override the global [shared cache mode] settings for individual database connections. <li>Added improved version identification features: C-Preprocessor macro [SQLITE_SOURCE_ID], C/C++ interface [sqlite3_sourceid()], and SQL function [sqlite_source_id()]. <li>Obscure bug fix on triggers (<a href="https://www.sqlite.org/src/info/efc02f9779">[efc02f9779]</a>). } chng {2009-08-10 (3.6.17)} { <li>Expose the [sqlite3_strnicmp()] interface for use by extensions and applications. <li>Remove the restriction on [virtual tables] and [shared cache mode]. Virtual tables and shared cache can now be used at the same time. |
︙ | ︙ | |||
3017 3018 3019 3020 3021 3022 3023 | [SQLITE_ENABLE_UPDATE_DELETE_LIMIT]. <li>Added the [sqlite3_stmt_status()] interface for performance monitoring.</li> <li>Add the [INDEXED BY] clause.</li> <li>The LOCKING_STYLE extension is now enabled by default on Mac OS X</li> <li>Added the TRUNCATE option to [PRAGMA journal_mode]</li> <li>Performance enhancements to tree balancing logic in the B-Tree layer.</li> <li>Added the | | | | 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 | [SQLITE_ENABLE_UPDATE_DELETE_LIMIT]. <li>Added the [sqlite3_stmt_status()] interface for performance monitoring.</li> <li>Add the [INDEXED BY] clause.</li> <li>The LOCKING_STYLE extension is now enabled by default on Mac OS X</li> <li>Added the TRUNCATE option to [PRAGMA journal_mode]</li> <li>Performance enhancements to tree balancing logic in the B-Tree layer.</li> <li>Added the <a href="https://www.sqlite.org/src/finfo?name=tool/genfkey.c"> source code</a> and <a href="https://www.sqlite.org/src/finfo?name=tool/genfkey.README"> documentation</a> for the <b>genfkey</b> program for automatically generating triggers to enforce foreign key constraints.</li> <li>Added the [SQLITE_OMIT_TRUNCATE_OPTIMIZATION] compile-time option.</li> <li>The <a href="lang.html">SQL language documentation</a> is converted to use <a href="syntaxdiagrams.html">syntax diagrams</a> instead of BNF.</li> <li>Other minor bug fixes</li> } |
︙ | ︙ | |||
3211 3212 3213 3214 3215 3216 3217 | the ".dump" output of databases with very large BLOBs and strings can be played back to recreate the database.</li> <li>Other small bug fixes and optimizations.</li> } chng {2007-11-27 (3.5.3)} { <li>Move website and documentation files out of the source tree into | | | 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 | the ".dump" output of databases with very large BLOBs and strings can be played back to recreate the database.</li> <li>Other small bug fixes and optimizations.</li> } chng {2007-11-27 (3.5.3)} { <li>Move website and documentation files out of the source tree into a <a href="https://www.sqlite.org/docsrc/">separate CM system</a>. <li>Fix a long-standing bug in INSERT INTO ... SELECT ... statements where the SELECT is compound. <li>Fix a long-standing bug in RAISE(IGNORE) as used in BEFORE triggers. <li>Fixed the operator precedence for the ~ operator. <li>On Win32, do not return an error when attempting to delete a file that does not exist. <li>Allow collating sequence names to be quoted. |
︙ | ︙ | |||
3308 3309 3310 3311 3312 3313 3314 | <li>Improvements to the amalgamation generator script so that all symbols are prefixed with either SQLITE_PRIVATE or SQLITE_API. } chng {2007-07-20 (3.4.1)} { <li>Fix a bug in <a href="lang_vacuum.html">VACUUM</a> that can lead to | | | 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 | <li>Improvements to the amalgamation generator script so that all symbols are prefixed with either SQLITE_PRIVATE or SQLITE_API. } chng {2007-07-20 (3.4.1)} { <li>Fix a bug in <a href="lang_vacuum.html">VACUUM</a> that can lead to <a href="https://www.sqlite.org/cvstrac/wiki?p=DatabaseCorruption"> database corruption</a> if two processes are connected to the database at the same time and one VACUUMs then the other then modifies the database.</li> <li>The expression "+column" is now considered the same as "column" when computing the collating sequence to use on the expression.</li> <li>In the <a href="tclsqlite.html">TCL language interface</a>, "@variable" instead of "$variable" always binds as a blob.</li> |
︙ | ︙ | |||
3341 3342 3343 3344 3345 3346 3347 | } chng {2007-06-18 (3.4.0)} { <li>Fix a bug that can lead to database corruption if an [SQLITE_BUSY] error occurs in the middle of an explicit transaction and that transaction is later committed. [Ticket #2409]. See the | | | 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 | } chng {2007-06-18 (3.4.0)} { <li>Fix a bug that can lead to database corruption if an [SQLITE_BUSY] error occurs in the middle of an explicit transaction and that transaction is later committed. [Ticket #2409]. See the <a href="https://www.sqlite.org/cvstrac/wiki?p=CorruptionFollowingBusyError"> CorruptionFollowingBusyError</a> wiki page for details.</i> <li>Fix a bug that can lead to database corruption if autovacuum mode is on and a malloc() failure follows a CREATE TABLE or CREATE INDEX statement which itself follows a cache overflow inside a transaction. See [ticket #2418]. </li> <li>Added explicit <a href="limits.html">upper bounds</a> on the sizes and |
︙ | ︙ | |||
3518 3519 3520 3521 3522 3523 3524 | } chng {2007-01-09 (3.3.10)} { <li>Fix bugs in the implementation of the new <a href="c3ref/prepare.html">sqlite3_prepare_v2()</a> API that can lead to segfaults.</li> <li>Fix 1-second round-off errors in the | | | 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 | } chng {2007-01-09 (3.3.10)} { <li>Fix bugs in the implementation of the new <a href="c3ref/prepare.html">sqlite3_prepare_v2()</a> API that can lead to segfaults.</li> <li>Fix 1-second round-off errors in the <a href="https://www.sqlite.org/cvstrac/wiki?p=DateAndTimeFunctions"> strftime()</a> function</li> <li>Enhance the Windows OS layer to provide detailed error codes</li> <li>Work around a win2k problem so that SQLite can use single-character database file names</li> <li>The <a href="pragma.html#pragma_user_version">user_version</a> and <a href="pragma.html#pragma_schema_version">schema_version</a> pragmas |
︙ | ︙ | |||
3565 3566 3567 3568 3569 3570 3571 | same directory as the original database</li> <li>The prefix on temporary filenames on Windows is changed from "sqlite" to "etilqs".</li> } chng {2006-10-09 (3.3.8)} { <li>Support for full text search using the | | | | | 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 | same directory as the original database</li> <li>The prefix on temporary filenames on Windows is changed from "sqlite" to "etilqs".</li> } chng {2006-10-09 (3.3.8)} { <li>Support for full text search using the <a href="https://www.sqlite.org/cvstrac/wiki?p=FullTextIndex">FTS1 module</a> (beta)</li> <li>Added Mac OS X locking patches (beta - disabled by default)</li> <li>Introduce extended error codes and add error codes for various kinds of I/O errors.</li> <li>Added support for IF EXISTS on CREATE/DROP TRIGGER/VIEW</li> <li>Fix the regression test suite so that it works with Tcl8.5</li> <li>Enhance sqlite3_set_authorizer() to provide notification of calls to SQL functions.</li> <li>Added experimental API: sqlite3_auto_extension()</li> <li>Various minor bug fixes</li> } chng {2006-08-12 (3.3.7)} { <li>Added support for <a href="https://www.sqlite.org/cvstrac/wiki?p=VirtualTables">virtual tables</a> (beta)</li> <li>Added support for <a href="https://www.sqlite.org/cvstrac/wiki?p=LoadableExtensions"> dynamically loaded extensions</a> (beta)</li> <li>The <a href="c3ref/interrupt.html">sqlite3_interrupt()</a> routine can be called for a different thread</li> <li>Added the <a href="lang_expr.html#match">MATCH</a> operator.</li> <li>The default file format is now 1. } |
︙ | ︙ | |||
4217 4218 4219 4220 4221 4222 4223 | another transaction is already active.</li> } chng {2002-08-13 (2.6.3)} { <li>Add the ability to read both little-endian and big-endian databases. So a database created under SunOS or Mac OS X can be read and written under Linux or Windows and vice versa.</li> | | | 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 | another transaction is already active.</li> } chng {2002-08-13 (2.6.3)} { <li>Add the ability to read both little-endian and big-endian databases. So a database created under SunOS or Mac OS X can be read and written under Linux or Windows and vice versa.</li> <li>Convert to the new website: https://www.sqlite.org/</li> <li>Allow transactions to span Linux Threads</li> <li>Bug fix in the processing of the ORDER BY clause for GROUP BY queries</li> } chng {2002-07-31 (2.6.2)} { <li>Text files read by the COPY command can now have line terminators of LF, CRLF, or CR.</li> |
︙ | ︙ | |||
5146 5147 5148 5149 5150 5151 5152 | } hd_resolve "</ol></p>\n" hd_resolve { <p>A [complete list of SQLite releases] in a single page and a [chronology] are both also available. A detailed history of every check-in is available at | | | 5146 5147 5148 5149 5150 5151 5152 5153 5154 5155 5156 5157 5158 5159 5160 5161 5162 5163 5164 5165 | } hd_resolve "</ol></p>\n" hd_resolve { <p>A [complete list of SQLite releases] in a single page and a [chronology] are both also available. A detailed history of every check-in is available at <a href="https://www.sqlite.org/src/timeline"> SQLite version control site</a>.</p> } hd_close_aux hd_enable_main 1 if {$i==0 && [file exists $DEST/$filename]} { file copy -force $DEST/$filename $DEST/releaselog/current.html } } } </tcl> </dl> |
Changes to pages/cintro.in.
︙ | ︙ | |||
421 422 423 424 425 426 427 | <li> [sqlite3_value_int | sqlite3_value()] </li> </ul></p> <p> All of the built-in SQL functions of SQLite are created using exactly these same interfaces. Refer to the SQLite source code, and in particular the | | | | 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 | <li> [sqlite3_value_int | sqlite3_value()] </li> </ul></p> <p> All of the built-in SQL functions of SQLite are created using exactly these same interfaces. Refer to the SQLite source code, and in particular the [https://www.sqlite.org/src/doc/trunk/src/date.c | date.c] and [https://www.sqlite.org/src/doc/trunk/src/func.c | func.c] source files for examples. </p> <p> Shared libraries or DLLs can be used as [loadable extensions] to SQLite. <h1>Other Interfaces</h1> |
︙ | ︙ |
Changes to pages/cli.in.
︙ | ︙ | |||
486 487 488 489 490 491 492 | <tclscript>DisplayCode { sqlite> (((SELECT writefile('icon.jpg',img) FROM images WHERE name='icon';))) }</tclscript> <p>Note that the readfile(X) and writefile(X,Y) functions are extension functions and are not built into the core SQLite library. These routines are available as a [loadable extension] in the | | | 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 | <tclscript>DisplayCode { sqlite> (((SELECT writefile('icon.jpg',img) FROM images WHERE name='icon';))) }</tclscript> <p>Note that the readfile(X) and writefile(X,Y) functions are extension functions and are not built into the core SQLite library. These routines are available as a [loadable extension] in the [https://www.sqlite.org/src/artifact?ci=trunk&filename=ext/misc/fileio.c|ext/misc/fileio.c] source file in the [SQLite source code repositories]. <tcl>hd_fragment editfunc {edit() SQL function}</tcl> <h2>The edit() SQL function</h2> <p>The CLI has another build-in SQL function named edit(). Edit() takes one or two arguments. The first argument is a value - usually a large |
︙ | ︙ | |||
804 805 806 807 808 809 810 | pathname of the extension. <p>SQLite computes the entry point for the extension based on the extension filename. To override this choice, simply add the name of the extension as a second argument to the ".load" command. <p>Source code for several useful extensions can be found in the | | | 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 | pathname of the extension. <p>SQLite computes the entry point for the extension based on the extension filename. To override this choice, simply add the name of the extension as a second argument to the ".load" command. <p>Source code for several useful extensions can be found in the <a href="https://www.sqlite.org/src/tree?name=ext/misc&ci=trunk">ext/misc</a> subdirectory of the SQLite source tree. You can use these extensions as-is, or as a basis for creating your own custom extensions to address your own particular needs. <tcl>hd_fragment sha3sum {.sha3sum dot-command}</tcl> <h1>Cryptographic Hashes Of Database Content</h1> |
︙ | ︙ | |||
1116 1117 1118 1119 1120 1121 1122 | statistics can be expensive for large database tables. If the operation is too slow, try passing a smaller value for the --sample option. </table> <p>Th functionality described in this section may be integrated into other applications or tools using the | | | 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 | statistics can be expensive for large database tables. If the operation is too slow, try passing a smaller value for the --sample option. </table> <p>Th functionality described in this section may be integrated into other applications or tools using the <a href="https://www.sqlite.org/src/dir?ci=trunk&name=ext/expert"> SQLite expert extension</a> code. <tcl>hd_fragment dotother</tcl> <h1>Other Dot Commands</h1> <p>There are many other dot-commands available in the command-line shell. See the ".help" command for a complete list for any particular |
︙ | ︙ |
Changes to pages/compile.in.
︙ | ︙ | |||
1075 1076 1077 1078 1079 1080 1081 | COMPILE_OPTION {SQLITE_ENABLE_SQLLOG} { This option enables extra code (especially the [SQLITE_CONFIG_SQLLOG] option to [sqlite3_config()]) that can be used to create logs of all SQLite processing performed by an application. These logs can be useful in doing off-line analysis of the behavior of an application, and especially for performance analysis. In order for the SQLITE_ENABLE_SQLLOG option to be useful, some extra code is required. The | | | 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 | COMPILE_OPTION {SQLITE_ENABLE_SQLLOG} { This option enables extra code (especially the [SQLITE_CONFIG_SQLLOG] option to [sqlite3_config()]) that can be used to create logs of all SQLite processing performed by an application. These logs can be useful in doing off-line analysis of the behavior of an application, and especially for performance analysis. In order for the SQLITE_ENABLE_SQLLOG option to be useful, some extra code is required. The <a href="https://www.sqlite.org/src/doc/trunk/src/test_sqllog.c">"test_sqllog.c"</a> source code file in the SQLite source tree is a working example of the required extra code. On unix and windows systems, a developer can append the text of the "test_sqllog.c" source code file to the end of an "sqlite3.c" amalgamation, recompile the application using the -DSQLITE_ENABLE_SQLLOG option, then control logging using environment variables. See the header comment on the "test_sqllog.c" source file for additional detail. |
︙ | ︙ | |||
1861 1862 1863 1864 1865 1866 1867 | A single function declaration should contain no more than one of the following: [SQLITE_APICALL], [SQLITE_CALLBACK], [SQLITE_CDECL], or [SQLITE_SYSCALL]. } COMPILE_OPTION {SQLITE_TCLAPI} { This macro specifies the calling convention used by the | | | 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 | A single function declaration should contain no more than one of the following: [SQLITE_APICALL], [SQLITE_CALLBACK], [SQLITE_CDECL], or [SQLITE_SYSCALL]. } COMPILE_OPTION {SQLITE_TCLAPI} { This macro specifies the calling convention used by the [https://www.tcl.tk | TCL] library interface routines. This macro is not used by the SQLite core, but only by the [TCL Interface] and [TCL test suite]. This macro is normally defined to be nothing, though on Windows builds it can sometimes be set to "__cdecl". This macro is used on TCL library interface routines which are always compiled as __cdecl, even on platforms that prefer to use __stdcall, so this macro should not be set to __stdcall unless the platform as a custom |
︙ | ︙ |
Changes to pages/dev.in.
1 2 3 4 | <title>SQLite Developer Links</title> <h1 align="center">Developer Resources</h1> <ul> | | | | | | 1 2 3 4 5 6 7 8 9 | <title>SQLite Developer Links</title> <h1 align="center">Developer Resources</h1> <ul> <li> <a href="https://www.sqlite.org/src/wiki?name=Bug+Reports">Report A Bug</a> <li> <a href="https://www.sqlite.org/src/timeline">Timeline</a> <li> <a href="https://www.sqlite.org/src/dir">Browse Historical Source Files</a> <li> <a href="https://www.sqlite.org/docsrc">Documentation Source Text</a> </ul> |
Changes to pages/download.in.
︙ | ︙ | |||
107 108 109 110 111 112 113 | [https://www.sqlite.org/draft/releaselog/current.html|change log] for more information. } Product {snapshot/sqlite-amalgamation-DATE.zip} { The [amalgamation]: complete source code a single "sqlite3.c" file. } # The [amalgamation] as of VERSION. | | | | | | | 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 | [https://www.sqlite.org/draft/releaselog/current.html|change log] for more information. } Product {snapshot/sqlite-amalgamation-DATE.zip} { The [amalgamation]: complete source code a single "sqlite3.c" file. } # The [amalgamation] as of VERSION. # See the <a href="https://www.sqlite.org/draft/releaselog/current.html">pending # change log</a> for details. Product {snapshot/sqlite-amalgamation32k-DATE.zip} { The [amalgamation] split into 6 separate source files each with less than 32767 lines of code. } # See the <a href="https://www.sqlite.org/draft/releaselog/current.html">pending # change log</a> for details. #Product {snapshot/sqlite-tea-DATE.zip} { # This is a snapshot (as of VERSION) of the current SQLite code under # development, packaged and ready to build using the # <a href="https://www.tcl.tk/doc/tea/">Tcl Extension Architecture (TEA)</a>. # Use this snapshot for testing only. This is not a release. #} Product {snapshot/sqlite-uap-DATE.vsix} { VSIX package for Universal Windows Platform development using Visual Studio 2015 CTP. } Product {snapshot/sqlite-uwp-DATE.vsix} { VSIX package for Universal Windows Platform development using Visual Studio 2015 CTP. } Heading {Pre-release Windows DLLs} {} $Caution Product snapshot/sqlite-dll-win32-x86-DATE.zip { A 32-bit Windows DLL as of VERSION. See the <a href="https://www.sqlite.org/draft/releaselog/current.html">pending change log</a> for details. } Product snapshot/sqlite-dll-win64-x64-DATE.zip { A 64-bit Windows DLL as of VERSION. See the <a href="https://www.sqlite.org/draft/releaselog/current.html">pending change log</a> for details. } Product {snapshot/sqlite-shell-win32-x86-DATE.zip} { This is a snapshot (as of VERSION) build of the [CLI | sqlite3.exe command-line shell] shell program for 32-bit windows. |
︙ | ︙ | |||
174 175 176 177 178 179 180 | Product {YEAR/sqlite-amalgamation32k-VVV.zip} { C source code as the [split amalgamation], version VERSION. } Product {YEAR/sqlite-autoconf-VVV.tar.gz} { C source code as an [amalgamation]. Also includes a "configure" script | | | | 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 | Product {YEAR/sqlite-amalgamation32k-VVV.zip} { C source code as the [split amalgamation], version VERSION. } Product {YEAR/sqlite-autoconf-VVV.tar.gz} { C source code as an [amalgamation]. Also includes a "configure" script and [https://www.tcl-lang.org/doc/tea/|TEA] makefiles for the [TCL Interface]. } {amalgtarball {amalgamation tarball}} Product {YEAR/sqlite-tea-VVV.tar.gz} { A tarball of the [amalgamation] together with a <a href="https://www.tcl-lang.org/doc/tea/">Tcl Extension Architecture (TEA)</a> compatible configure script and makefile. } {teatarball {TEA tarball}} Heading {Documentation} docco Product {YEAR/sqlite-doc-VVV.zip} { |
︙ | ︙ | |||
347 348 349 350 351 352 353 | 2013. } if {$nDownload>$start} { hd_puts {<tr><td colspan="4"><b>Precompiled Binaries for .NET</b></td></tr>} hd_puts "<tr><td width=\"10\"></td>" hd_puts "<td valign=\"top\" align=\"right\">" | | | | 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 | 2013. } if {$nDownload>$start} { hd_puts {<tr><td colspan="4"><b>Precompiled Binaries for .NET</b></td></tr>} hd_puts "<tr><td width=\"10\"></td>" hd_puts "<td valign=\"top\" align=\"right\">" set url https://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki hd_puts "<a href=\"$url\">System.Data.SQLite</a></td>" hd_puts "<td width=\"5\"></td>" hd_puts "<td valign=\"top\">" hd_puts " Visit the <a href=\"https://system.data.sqlite.org/\">System.Data.SQLite.org </a> website and especially the <a href=\"$url\">download page</a> for source code and binaries of SQLite for .NET.</td></tr> " } Heading {Alternative Source Code Formats} old |
︙ | ︙ | |||
408 409 410 411 412 413 414 | <a name="fossil"></a> <tcl>hd_fragment srctree {SQLite source code repositories} {code repositories}</tcl> <h3>Source Code Repositories</h3> <p> The SQLite source code is maintained in three geographically-dispersed self-synchronizing | | | | | 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 | <a name="fossil"></a> <tcl>hd_fragment srctree {SQLite source code repositories} {code repositories}</tcl> <h3>Source Code Repositories</h3> <p> The SQLite source code is maintained in three geographically-dispersed self-synchronizing [https://www.fossil-scm.org/ | Fossil] repositories that are available for anonymous read-only access. Anyone can view the repository contents and download historical versions of individual files or ZIP archives of historical check-ins. You can also [clone the entire repository].</p> <p>See the [How To Compile SQLite] page for additional information on how to use the raw SQLite source code. Note that a recent version of <a href="https://www.tcl.tk/">Tcl</a> is required in order to build from the repository sources. The [amalgamation] source code files (the "sqlite3.c" and "sqlite3.h" files) build products and are not contained in raw source code tree.</p> <blockquote> <a href="https://www.sqlite.org/cgi/src">https://www.sqlite.org/cgi/src</a> (Dallas)<br> <a href="https://www2.sqlite.org/cgi/src">https://www2.sqlite.org/cgi/src</a> (Newark)<br> <a href="https://www3.sqlite.org/cgi/src">https://www3.sqlite.org/cgi/src</a> (San Francisco)<br> </blockquote> <p>The documentation is maintained in separate [https://www.fossil-scm.org/ | Fossil] repositories located at:</p> <blockquote> <a href="https://www.sqlite.org/cgi/docsrc">https://www.sqlite.org/cgi/docsrc</a> (Dallas)<br> <a href="https://www2.sqlite.org/cgi/docsrc">https://www2.sqlite.org/cgi/docsrc</a> (Newark)<br> <a href="https://www3.sqlite.org/cgi/docsrc">https://www3.sqlite.org/cgi/docsrc</a> (San Francisco)<br> </blockquote> |
︙ | ︙ |
Changes to pages/famous.in.
︙ | ︙ | |||
137 138 139 140 141 142 143 | } famous_user skype http://www.skype.com/ skype.gif { There are [http://www.mail-archive.com/sqlite-users%40sqlite.org/msg27326.html | multiple] [http://www.mail-archive.com/sqlite-users%40sqlite.org/msg27332.html|sightings] of SQLite in the Skype client for Mac OS X and Windows. } | | | 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 | } famous_user skype http://www.skype.com/ skype.gif { There are [http://www.mail-archive.com/sqlite-users%40sqlite.org/msg27326.html | multiple] [http://www.mail-archive.com/sqlite-users%40sqlite.org/msg27332.html|sightings] of SQLite in the Skype client for Mac OS X and Windows. } famous_user tcl https://www.tcl.tk/ tcl.gif { The Tcl/Tk programming language now comes with SQLite built-in. SQLite works particularly well with Tcl since SQLite was originally a Tcl extension that subsequently "escaped" into the wild. } famous_user loc http://www.loc.gov/ loc.jpg { The United States Library of Congress recognizes SQLite as a [recommended storage format] for preservation of digital content. |
︙ | ︙ |
Changes to pages/faq.in.
︙ | ︙ | |||
575 576 577 578 579 580 581 | <tt>column1=column1</tt> which is obviously always true. } faq { How are the syntax diagrams (a.k.a. "railroad" diagrams) for SQLite generated? } { | | | 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 | <tt>column1=column1</tt> which is obviously always true. } faq { How are the syntax diagrams (a.k.a. "railroad" diagrams) for SQLite generated? } { The process is explained at [http://wiki.tcl.tk/21708]. } faq { The SQL standard requires that a UNIQUE constraint be enforced even if one or more of the columns in the constraint are NULL, but SQLite does not do this. Isn't that a bug? } { |
︙ | ︙ |
Changes to pages/fileformat2.in.
︙ | ︙ | |||
361 362 363 364 365 366 367 | can be set by the [PRAGMA application_id] command in order to identify the database as belonging to or associated with a particular application. The application ID is intended for database files used as an [application file-format]. The application ID can be used by utilities such as [http://www.darwinsys.com/file/ | file(1)] to determine the specific file type rather than just reporting "SQLite3 Database". A list of assigned application IDs can be seen by consulting the | | | 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 | can be set by the [PRAGMA application_id] command in order to identify the database as belonging to or associated with a particular application. The application ID is intended for database files used as an [application file-format]. The application ID can be used by utilities such as [http://www.darwinsys.com/file/ | file(1)] to determine the specific file type rather than just reporting "SQLite3 Database". A list of assigned application IDs can be seen by consulting the [https://www.sqlite.org/src/artifact?ci=trunk&filename=magic.txt|magic.txt] file in the SQLite source repository.</p> <tcl>hd_fragment validfor {version-valid-for number}</tcl> <h3>Write library version number and version-valid-for number</h3> <p>^The 4-byte big-endian integer at offset 96 stores the [SQLITE_VERSION_NUMBER] value for the SQLite library that most |
︙ | ︙ |
Changes to pages/fts3.in.
︙ | ︙ | |||
2910 2911 2912 2913 2914 2915 2916 | of references etc.). These values can be stored by the application in a separate table that can be joined against the documents table in the sub-query so that the rank function may access them. </ol> <p> This version of the query is very similar to that used by the | | | 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 | of references etc.). These values can be stored by the application in a separate table that can be joined against the documents table in the sub-query so that the rank function may access them. </ol> <p> This version of the query is very similar to that used by the <a href="https://www.sqlite.org/search?q=fts3">sqlite.org documentation search</a> application. <codeblock> <i>-- This table stores the static weight assigned to each document in FTS table</i> <i>-- "documents". For each row in the documents table there is a corresponding row</i> <i>-- with the same docid value in this table.</i> CREATE TABLE documents_data(docid INTEGER PRIMARY KEY, weight); |
︙ | ︙ |
Changes to pages/fts5.in.
︙ | ︙ | |||
1966 1967 1968 1969 1970 1971 1972 | FTS5 table. This shadow table is not present for [FTS5 contentless tables | contentless] or [FTS5 external content tables|external content] FTS5 tables. <tr><td><name>_docsize<td> Contains the size of each column of each row in the virtual table in tokens. This shadow table is not present if the [FTS5 columnsize option|"columnsize" option] is set to 0. </table> | < < < < | 1966 1967 1968 1969 1970 1971 1972 | FTS5 table. This shadow table is not present for [FTS5 contentless tables | contentless] or [FTS5 external content tables|external content] FTS5 tables. <tr><td><name>_docsize<td> Contains the size of each column of each row in the virtual table in tokens. This shadow table is not present if the [FTS5 columnsize option|"columnsize" option] is set to 0. </table> |
Changes to pages/getthecode.in.
︙ | ︙ | |||
22 23 24 25 26 27 28 | Even if the specific version desired is not listed on the download page, the naming conventions are fairly clear and so programmers can often guess the name of an historical release and download it that way. <h1>Obtaining Code Directly From the Version Control System</h1> <p>For any historical version of SQLite, the source tree can be obtained | | | 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 | Even if the specific version desired is not listed on the download page, the naming conventions are fairly clear and so programmers can often guess the name of an historical release and download it that way. <h1>Obtaining Code Directly From the Version Control System</h1> <p>For any historical version of SQLite, the source tree can be obtained from the [https://www.fossil-scm.org/|Fossil] version control system, either downloading a tarball or ZIP archive for a specific version, or by cloning the entire project history. <p>SQLite sources are maintained on three geographically dispersed servers: <blockquote> |
︙ | ︙ | |||
46 47 48 49 50 51 52 | [https://www.sqlite.org/cgi/docsrc] (Dallas)<br> [https://www2.sqlite.org/cgi/docsrc] (Newark)<br> [https://www3.sqlite.org/cgi/docsrc] (San Francisco)<br> </blockquote> <p>To download a specific historical version, first locate the specific version desired by visiting the timeline page on one of these servers | | | | | | 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 | [https://www.sqlite.org/cgi/docsrc] (Dallas)<br> [https://www2.sqlite.org/cgi/docsrc] (Newark)<br> [https://www3.sqlite.org/cgi/docsrc] (San Francisco)<br> </blockquote> <p>To download a specific historical version, first locate the specific version desired by visiting the timeline page on one of these servers (for example: [https://www.sqlite.org/cgi/src/timeline]). If you know the approximate date of the version you want to download, you can add a query parameter like "c=YYYY-MM-DD" to the "timeline" URL to see a timeline centered on that date. For example, to see all the check-ins that occurred around August 26, 2013, visit [https://www.sqlite.org/cgi/src/timeline?c=2013-08-26]. If you are looking for an official release, visit the [chronology] page, click on the date to the left of the release you are looking for, and that will take you immediately to the check-in corresponding to the release. <p>Once you locate a specific version, click on the hyperlink for that version to see the "Check-in Information Page". Then click on either the "Tarball" link or the "ZIP archive" link to download the complete source tree. <tcl>hd_fragment {clone} {clone the entire repository}</tcl> <h1>Cloning The Complete Development History</h1> <p>To clone the entire history of SQLite, first go to the [https://www.fossil-scm.org/download.html] page and grab a precompiled binary for the Fossil version control program. Or get the source code on the same page and compile it yourself. <p>As of 2017-03-12, you must use Fossil version 2.0 or later for the following instructions to work. The SQLite repository started using artifacts named using SHA3 hashes instead of SHA1 hashes on that date, and Fossil 2.0 or later is needed in order to understand the new SHA3 hashes. To find out what version of Fossil you are running, type "fossil -v".</p> <p>Fossil is a completely stand-alone program, so install it simply by putting the "fossil" or "fossil.exe" executable someplace on your $PATH or %PATH%. After you have Fossil installed, do this: <codeblock> fossil clone https://www.sqlite.org/cgi/src sqlite.fossil </codeblock> <p>The command above will make a copy of the complete development history of SQLite into the "sqlite.fossil" file on your computer. Making this copy takes about a minute and uses about 32 megabytes of transfer. After making the copy, "open" the repository by typing: |
︙ | ︙ | |||
110 111 112 113 114 115 116 | </codeblock> <p>Where VERSION can be a branch name (like "trunk" or "session") to get the latest check-in on a specific branch, or VERSION can be a SHA1 hash or a prefix of a SHA1 hash for a specific check-in, or VERSION can be a tag such as "version-3.8.8". Every time you run "fossil update" it will automatically reach out to the original repository at | | | 110 111 112 113 114 115 116 117 118 | </codeblock> <p>Where VERSION can be a branch name (like "trunk" or "session") to get the latest check-in on a specific branch, or VERSION can be a SHA1 hash or a prefix of a SHA1 hash for a specific check-in, or VERSION can be a tag such as "version-3.8.8". Every time you run "fossil update" it will automatically reach out to the original repository at https://www.sqlite.org/cgi/src to obtain new check-ins that might have been made by others since your previous update. |
Changes to pages/howtocompile.in.
︙ | ︙ | |||
143 144 145 146 147 148 149 | <h1>Compiling The TCL Interface</h1> <p>The TCL interface for SQLite is a small module that is added into the regular amalgamation. The result is a new amalgamated source file called "<b>tclsqlite3.c</b>". This single source file is all that is needed to generate a shared library that can be loaded into a standard | | | | | 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 | <h1>Compiling The TCL Interface</h1> <p>The TCL interface for SQLite is a small module that is added into the regular amalgamation. The result is a new amalgamated source file called "<b>tclsqlite3.c</b>". This single source file is all that is needed to generate a shared library that can be loaded into a standard [https://wiki.tcl.tk/2541 | tclsh] or [https://wiki.tcl.tk/2364 | wish] using the [https://wiki.tcl.tk/9830 | TCL load command], or to generate a standalone tclsh that comes with SQLite built in. A copy of the tcl amalgamation is included on the [download page] as a file in the [TEA tarball].</p> <p>To generate a TCL-loadable library for SQLite on Linux, the following command will suffice:</p> |
︙ | ︙ | |||
217 218 219 220 221 222 223 | </ul> <p>To build a custom amalgamation, first download the original individual source files onto a unix or unix-like development platform. Be sure to get the original source files not the "preprocessed source files". One can obtain the complete set of original source files either from the [download page] or directly | | | 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 | </ul> <p>To build a custom amalgamation, first download the original individual source files onto a unix or unix-like development platform. Be sure to get the original source files not the "preprocessed source files". One can obtain the complete set of original source files either from the [download page] or directly from the [https://www.sqlite.org/src | configuration management system].</p> <p>Suppose the SQLite source tree is stored in a directory named "sqlite". Plan to construct the amalgamation in a parallel directory named (for example) "bld". First construct an appropriate Makefile by either running the configure script at the top of the SQLite source tree, or by making a copy of one of the template Makefiles at the top of the source tree. Then hand edit this Makefile to include the desired compile-time options. |
︙ | ︙ | |||
250 251 252 253 254 255 256 | <tcl>hd_fragment {dll} {building a DLL}</tcl> <h1>Building A Windows DLL</h1> <p>To build a DLL of SQLite for use in Windows, first acquire the appropriate amalgamated source code files, sqlite3.c and sqlite3.h. These can either | | | 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 | <tcl>hd_fragment {dll} {building a DLL}</tcl> <h1>Building A Windows DLL</h1> <p>To build a DLL of SQLite for use in Windows, first acquire the appropriate amalgamated source code files, sqlite3.c and sqlite3.h. These can either be downloaded from the [https://www.sqlite.org/download.html | SQLite website] or custom generated from sources as shown above.</p> <p>With source code files in the working directory, a DLL can be generated using MSVC with the following command: <blockquote><pre> cl sqlite3.c -link -dll -out:sqlite3.dll |
︙ | ︙ |
Changes to pages/howtocorrupt.in.
︙ | ︙ | |||
32 33 34 35 36 37 38 | old file descriptor, not realizing that the original file had been closed already. But because the file descriptor had been reopened by SQLite, the information that was intended to go into the original file ended up overwriting parts of the SQLite database, leading to corruption of the database.</p> <p>One example of this occurred circa 2013-08-30 on the canonical repository | | | 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 | old file descriptor, not realizing that the original file had been closed already. But because the file descriptor had been reopened by SQLite, the information that was intended to go into the original file ended up overwriting parts of the SQLite database, leading to corruption of the database.</p> <p>One example of this occurred circa 2013-08-30 on the canonical repository for the <a href="https://www.fossil-scm.org/">Fossil DVCS</a>. In that event, file descriptor 2 (standard error) was being erroneously closed (by [http://www.stunnel.org/|stunnel], we suspect) prior to [sqlite3_open_v2()] so that the file descriptor used for the repository database file was 2. Later, an application bug caused an assert() statement to emit an error message by invoking write(2,...). But since file descriptor 2 was now connected to a database file, the error message |
︙ | ︙ | |||
408 409 410 411 412 413 414 | <tcl>hd_fragment fscorruption {filesystem corruption}</tcl> <h2> Filesystem Corruption</h2> <p>Since SQLite databases are ordinary disk files, any malfunction in the filesystem can corrupt the database. Filesystems in modern operating systems are very reliable, but errors do still occur. For example, on 2013-10-01 the SQLite database that holds the | | | 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 | <tcl>hd_fragment fscorruption {filesystem corruption}</tcl> <h2> Filesystem Corruption</h2> <p>Since SQLite databases are ordinary disk files, any malfunction in the filesystem can corrupt the database. Filesystems in modern operating systems are very reliable, but errors do still occur. For example, on 2013-10-01 the SQLite database that holds the <a href="http://wiki.tcl.tk/">Wiki for Tcl/Tk</a> went corrupt a few days after the host computer was moved to a dodgy build of the (linux) kernel that had issues in the filesystem layer. In that event, the filesystem eventually became so badly corrupted that the machine was unusable, but the earliest symptom of trouble was the corrupted SQLite database.</p> <tcl>hd_fragment cfgerr cfgerrors*</tcl> <h1>SQLite Configuration Errors</h1> |
︙ | ︙ |
Changes to pages/lang.in.
︙ | ︙ | |||
1980 1981 1982 1983 1984 1985 1986 | </tr> <tr> <td align="right" valign="top"><b>$</b><i>AAAA</i></td><td width="20"></td> <td>^A dollar-sign followed by an identifier name also holds a spot for a named parameter with the name $AAAA. ^(The identifier name in this case can include one or more occurrences of "::" and a suffix enclosed in "(...)" containing any text at all.)^ This syntax is the form of a variable name in the | | | 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 | </tr> <tr> <td align="right" valign="top"><b>$</b><i>AAAA</i></td><td width="20"></td> <td>^A dollar-sign followed by an identifier name also holds a spot for a named parameter with the name $AAAA. ^(The identifier name in this case can include one or more occurrences of "::" and a suffix enclosed in "(...)" containing any text at all.)^ This syntax is the form of a variable name in the [https://www.tcl.tk/ | Tcl programming language]. The presence of this syntax results from the fact that SQLite is really a [Tcl extension] that has escaped into the wild.</td> </tr> </table> </blockquote> <p>^Parameters that are not assigned values using |
︙ | ︙ | |||
3888 3889 3890 3891 3892 3893 3894 | child checkin is no less than the mtime of all its parents. But unlike the earlier examples, this graph might have multiple paths of differing lengths between any two checkins. <p>We want to know the twenty most recent ancestors in time (out of the thousands and thousands of ancestors in the whole DAG) for checkin "@BASELINE". (A query similar to this is used | | | | 3888 3889 3890 3891 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 | child checkin is no less than the mtime of all its parents. But unlike the earlier examples, this graph might have multiple paths of differing lengths between any two checkins. <p>We want to know the twenty most recent ancestors in time (out of the thousands and thousands of ancestors in the whole DAG) for checkin "@BASELINE". (A query similar to this is used by the <a href="https://www.fossil-scm.org/">Fossil</a> VCS to show the N most recent ancestors of a check. For example: <a href="https://www.sqlite.org/src/timeline?p=trunk&n=30">https://www.sqlite.org/src/timeline?p=trunk&n=30</a>.) <blockquote><pre> WITH RECURSIVE ancestor(id,mtime) AS ( SELECT id, mtime FROM checkin WHERE id=@BASELINE UNION SELECT derivedfrom.xfrom, checkin.mtime |
︙ | ︙ |
Changes to pages/lockingv3.in.
︙ | ︙ | |||
57 58 59 60 61 62 63 | of SQLite version 3. </p> <tcl>HEADING 1 {Overview} overview</tcl> <p> Locking and concurrency control are handled by the | | | | | 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 | of SQLite version 3. </p> <tcl>HEADING 1 {Overview} overview</tcl> <p> Locking and concurrency control are handled by the <a href="https://www.sqlite.org/src/finfo?name=src/pager.c"> pager module</a>. The pager module is responsible for making SQLite "ACID" (Atomic, Consistent, Isolated, and Durable). The pager module makes sure changes happen all at once, that either all changes occur or none of them do, that two or more processes do not try to access the database in incompatible ways at the same time, and that once changes have been written they persist until explicitly deleted. The pager also provides a memory cache of some of the contents of the disk file.</p> <p>The pager is unconcerned with the details of B-Trees, text encodings, indices, and so forth. From the point of view of the pager the database consists of a single file of uniform-sized blocks. Each block is called a "page" and is usually 1024 bytes in size. The pages are numbered beginning with 1. So the first 1024 bytes of the database are called "page 1" and the second 1024 bytes are call "page 2" and so forth. All other encoding details are handled by higher layers of the library. The pager communicates with the operating system using one of several modules (Examples: <a href="https://www.sqlite.org/src/finfo?name=src/os_unix.c"> os_unix.c</a>, <a href="https://www.sqlite.org/src/finfo?name=src/os_win.c"> os_win.c</a>) that provides a uniform abstraction for operating system services. </p> <p>The pager module effectively controls access for separate threads, or separate processes, or both. Throughout this document whenever the word "process" is written you may substitute the word "thread" without |
︙ | ︙ |
Changes to pages/news.in.
︙ | ︙ | |||
10 11 12 13 14 15 16 | {<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 \ | | | 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | {<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="https://www.sqlite.org/cvstrac/tktview?tn=\1">\0</a>} txt hd_resolve "<blockquote>$txt</blockquote>" hd_puts "<hr width=\"50%\">" } newsitem {2018-06-04} {Release 3.24.0} { SQLite [version 3.24.0] is a regularly scheduled maintenance release. Highlights of this release include support for PostgreSQL-style |
︙ | ︙ |
Changes to pages/oldnews.in.
︙ | ︙ | |||
266 267 268 269 270 271 272 | <p>This release contains the usual assortment of obscure bug fixes. One bug, however, deserves special attention. A problem appeared in the [CREATE INDEX] command beginning with [version 3.8.2] (2013-12-06) that allowed, under some circumstances, a UNIQUE index to be created on a column that was not unique. Once the index was created, no new non-unique entries could be inserted, but preexisting non-unique entries would remain. See ticket | | | | 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 | <p>This release contains the usual assortment of obscure bug fixes. One bug, however, deserves special attention. A problem appeared in the [CREATE INDEX] command beginning with [version 3.8.2] (2013-12-06) that allowed, under some circumstances, a UNIQUE index to be created on a column that was not unique. Once the index was created, no new non-unique entries could be inserted, but preexisting non-unique entries would remain. See ticket [https://www.sqlite.org/src/info/9a6daf340df99ba93c|9a6daf340df99ba93c] for further information. In addition to fixing this bug, the [PRAGMA integrity_check] command has been enhanced to detect non-uniqueness in UNIQUE indices, so that if this bug did introduce any problems in databases, those problems can be easily detected. <p>Other noteworthy changes include the addition of support for [hexadecimal integers] (ex: 0x1234), and performance enhancements to the [IN operator] which, according to [http://www.mail-archive.com/sqlite-users%40sqlite.org/msg85350.html|mailing list reports], help some queries run up to five times faster. <p>Version 3.8.6 uses 25% fewer CPU cycles than version 3.8.0 from approximately one year ago, according to [http://valgrind.org/|valgrind] and the [https://www.sqlite.org/src/artifact/d29c8048beb7e|test/speedtest1.c] test program. On the other hand, the compiled binary for version 3.8.6 is about 5% larger than 3.8.0. The size increase is due in part to the addition of new features such as [WITHOUT ROWID] tables and [common table expressions]. } |
︙ | ︙ | |||
312 313 314 315 316 317 318 | the change log for details. } 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 | | | | | 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 | the change log for details. } 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 [https://www.sqlite.org/src/info/98825a79ce145686392d8074032ae54863aa21a3| ticket 98825a79ce145] for details. This release adds a [https://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 [https://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} { |
︙ | ︙ | |||
379 380 381 382 383 384 385 | </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 | | | 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 | </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 [[https://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. |
︙ | ︙ | |||
439 440 441 442 443 444 445 | 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 | | | 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 | 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 [https://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 |
︙ | ︙ | |||
527 528 529 530 531 532 533 | 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. | | | 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 | 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 [https://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. |
︙ | ︙ | |||
552 553 554 555 556 557 558 | 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 | | | | 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 | 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 [https://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 [https://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. } |
︙ | ︙ | |||
705 706 707 708 709 710 711 | The next release of SQLite is scheduled to occur after the usual 2 or 3 month interval. } newsitem {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 | | | | 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 | The next release of SQLite is scheduled to occur after the usual 2 or 3 month interval. } newsitem {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 [https://www.sqlite.org/src/info/c2ad16f997ee9c | 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. } newsitem {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 [version 3.7.12 | change summary] for details. } newsitem {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 [https://www.sqlite.org/src/info/b7c8682cc1 | 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 |
︙ | ︙ | |||
778 779 780 781 782 783 784 | depend on the database page size. Now, if you give [PRAGMA cache_size] a negative value -N, it will allocate roughly N [http://en.wikipedia.org/wiki/Kibibyte | 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, | | | 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 | depend on the database page size. Now, if you give [PRAGMA cache_size] a negative value -N, it will allocate roughly N [http://en.wikipedia.org/wiki/Kibibyte | 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 [https://www.sqlite.org/src/info/ff5be73dee | 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. } |
︙ | ︙ | |||
849 850 851 852 853 854 855 | 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. } newsitem {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 | | | 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 | 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. } newsitem {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 [https://www.sqlite.org/src/info/25ee812710 | 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. |
︙ | ︙ | |||
899 900 901 902 903 904 905 | 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. } newsitem {2011-05-19} {Version 3.7.6.3} { SQLite [version 3.7.6.3] is a patch release that fixes a | | | 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 | 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. } newsitem {2011-05-19} {Version 3.7.6.3} { SQLite [version 3.7.6.3] is a patch release that fixes a [https://www.sqlite.org/src/info/2d1a5c67df | 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 |
︙ | ︙ | |||
972 973 974 975 976 977 978 | release of SQLite. Upgrading from version 3.7.5 is optional. Upgrading releases prior to 3.7.5 is recommended. } newsitem {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 | | | 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 | release of SQLite. Upgrading from version 3.7.5 is optional. Upgrading releases prior to 3.7.5 is recommended. } newsitem {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 [https://www.sqlite.org/src/tktview?name=5d863f876e | 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 [SQLITE_DBSTATUS_LOOKASIDE_HIT | opcodes] for the [sqlite3_db_status()] interface that allow more precise measurement of how the [lookaside memory allocator] is performing, which can be useful |
︙ | ︙ | |||
1033 1034 1035 1036 1037 1038 1039 | <li> WinXP and Win7 <li> Android 2.2 <li> OpenBSD 4.7 </ul> The previous release of SQLite ([version 3.7.3]) has proven to be very robust. The only serious issue discovered was | | | 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 | <li> WinXP and Win7 <li> Android 2.2 <li> OpenBSD 4.7 </ul> The previous release of SQLite ([version 3.7.3]) has proven to be very robust. The only serious issue discovered was [https://www.sqlite.org/src/info/80ba201079 | 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. } |
︙ | ︙ | |||
1069 1070 1071 1072 1073 1074 1075 | newsitem {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 | | | 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 | newsitem {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 <a href="https://www.sqlite.org/src/info/5e10420e8d">here</a>. 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 |
︙ | ︙ | |||
1160 1161 1162 1163 1164 1165 1166 | an anachronism. } newsitem {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. <ul> | | | | 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 | an anachronism. } newsitem {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. <ul> <li>Ticket [https://www.sqlite.org/src/info/31338dca7e | 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. <li> Ticket [https://www.sqlite.org/src/info/eb5548a849 | 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. </ul> Both bugs are obscure, but because they could arise in an application after deployment, it is |
︙ | ︙ | |||
1214 1215 1216 1217 1218 1219 1220 | 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. } newsitem {2009-09-11} {Version 3.6.18} { Beginning with this release, the SQLite source code is tracked and | | | 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 | 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. } newsitem {2009-09-11} {Version 3.6.18} { Beginning with this release, the SQLite source code is tracked and managed using the [https://www.fossil-scm.org/ | 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 |
︙ | ︙ | |||
1292 1293 1294 1295 1296 1297 1298 | SQLite [version 3.6.15] is a general maintenance release containing performance and robustness enhancements and fixes for various obscure bugs. } newsitem {2009-05-25} {Version 3.6.14.2} { SQLite [version 3.6.14.2] fixes an obscure bug in the code generator | | | | 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 | SQLite [version 3.6.15] is a general maintenance release containing performance and robustness enhancements and fixes for various obscure bugs. } newsitem {2009-05-25} {Version 3.6.14.2} { SQLite [version 3.6.14.2] fixes an obscure bug in the code generator (<a href="https://www.sqlite.org/cvstrac/tktview?tn=3879">ticket #3879</a>) 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 <a href="https://www.sqlite.org/cvstrac/chngview?cn=6676">[6676]</a> 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. |
︙ | ︙ | |||
1542 1543 1544 1545 1546 1547 1548 | allocation subsystem in future releases. } newsitem {2007-10-04} {Version 3.5.1} { Fix a long-standing bug that might cause database corruption if a disk-full error occurs in the middle of a transaction and that transaction is not rolled back. | | | 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 | allocation subsystem in future releases. } newsitem {2007-10-04} {Version 3.5.1} { Fix a long-standing bug that might cause database corruption if a disk-full error occurs in the middle of a transaction and that transaction is not rolled back. <a href="https://www.sqlite.org/cvstrac/tktview?tn=2686">Ticket #2686.</a> The new VFS layer is stable. However, we still reserve the right to make tweaks to the interface definition of the VFS if necessary. } newsitem {2007-09-04} {Version 3.5.0 alpha} { The OS interface layer and the memory allocation subsystems in |
︙ | ︙ | |||
1566 1567 1568 1569 1570 1571 1572 | freeze the new design. } newsitem {2007-08-13} {Version 3.4.2} { While stress-testing the <a href="c3ref/soft_heap_limit.html">soft_heap_limit</a> feature, a bug that could lead to | | | | | | | 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 | freeze the new design. } newsitem {2007-08-13} {Version 3.4.2} { While stress-testing the <a href="c3ref/soft_heap_limit.html">soft_heap_limit</a> feature, a bug that could lead to <a href="https://www.sqlite.org/cvstrac/wiki?p=DatabaseCorruption">database corruption</a> was <a href="https://www.sqlite.org/cvstrac/tktview?tn=2565"> discovered and fixed</a>. Though the consequences of this bug are severe, the chances of hitting it in a typical application are remote. Upgrading is recommended only if you use the <a href="c3ref/soft_heap_limit.html">sqlite3_soft_heap_limit</a> interface. } newsitem {2007-07-20} {Version 3.4.1} { This release fixes a bug in <a href="lang_vacuum.html">VACUUM</a> that can lead to <a href="https://www.sqlite.org/cvstrac/wiki?p=DatabaseCorruption"> database corruption</a>. The bug was introduced in version <a href="changes.html#version_3_3_14">3.3.14</a>. Upgrading is recommended for all users. Also included are a slew of other more routine <a href="changes.html#version_3_4_1">enhancements and bug fixes</a>. } newsitem {2007-06-18} {Version 3.4.0} { This release fixes two separate bugs either of which can lead to database corruption. Upgrading is strongly recommended. If you must continue using an older version of SQLite, please at least read about how to avoid these bugs at <a href="https://www.sqlite.org/cvstrac/wiki?p=CorruptionFollowingBusyError"> CorruptionFollowingBusyError</a> and <a href="https://www.sqlite.org/cvstrac/tktview?tn=2418">ticket #2418</a> <p> This release also adds explicit <a href="limits.html">limits</a> on the sizes and quantities of things SQLite will handle. The new limits might causes compatibility problems for existing applications that use excessively large strings, BLOBs, tables, or SQL statements. The new limits can be increased at compile-time to work around any problems that arise. Nevertheless, the version number of this release is |
︙ | ︙ | |||
1633 1634 1635 1636 1637 1638 1639 | newsitem {2007-04-09} {Version 3.3.15} { An annoying bug introduced in 3.3.14 has been fixed. There are also many enhancements to the test suite. } newsitem {2007-04-02} {Version 3.3.14} { This version focuses on performance improvements. If you recompile | | | 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 | newsitem {2007-04-09} {Version 3.3.15} { An annoying bug introduced in 3.3.14 has been fixed. There are also many enhancements to the test suite. } newsitem {2007-04-02} {Version 3.3.14} { This version focuses on performance improvements. If you recompile <a href="https://www.sqlite.org/cvstrac/wiki?p=TheAmalgamation"> the amalgamation</a> using GCC option -O3 (the precompiled binaries use -O2) you may see performance improvements of 35% or more over version 3.3.13 depending on your workload. This version also adds support for <a href="pragma.html#pragma_locking_mode"> exclusive access mode</a>. } |
︙ | ︙ | |||
1670 1671 1672 1673 1674 1675 1676 | Version 3.3.10 fixes several bugs that were introduced by the previous release. Upgrading is recommended. } newsitem {2007-01-04} {Version 3.3.9} { Version 3.3.9 fixes bugs that can lead to database corruption under obscure and difficult to reproduce circumstances. See | | | | | 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 | Version 3.3.10 fixes several bugs that were introduced by the previous release. Upgrading is recommended. } newsitem {2007-01-04} {Version 3.3.9} { Version 3.3.9 fixes bugs that can lead to database corruption under obscure and difficult to reproduce circumstances. See <a href="https://www.sqlite.org/cvstrac/wiki?p=DatabaseCorruption"> DatabaseCorruption</a> in the <a href="https://www.sqlite.org/cvstrac/wiki">wiki</a> for details. This release also adds the new <a href="c3ref/prepare.html">sqlite3_prepare_v2()</a> API and includes important bug fixes in the command-line shell and enhancements to the query optimizer. Upgrading is recommended. } newsitem {2006-10-09} {Version 3.3.8} { Version 3.3.8 adds support for full-text search using the <a href="https://www.sqlite.org/cvstrac/wiki?p=FtsOne">FTS1 module.</a> There are also minor bug fixes. Upgrade only if you want to try out the new full-text search capabilities or if you are having problems with 3.3.7. } newsitem {2006-08-12} {Version 3.3.7} { Version 3.3.7 includes support for loadable extensions and virtual |
︙ | ︙ | |||
1747 1748 1749 1750 1751 1752 1753 | the library is running much faster again. Database connections can now be moved between threads as long as the connection holds no locks at the time it is moved. Thus the common paradigm of maintaining a pool of database connections and handing them off to transient worker threads is now supported. Please help test this new feature. | | | 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 | the library is running much faster again. Database connections can now be moved between threads as long as the connection holds no locks at the time it is moved. Thus the common paradigm of maintaining a pool of database connections and handing them off to transient worker threads is now supported. Please help test this new feature. See <a href="https://www.sqlite.org/cvstrac/wiki?p=MultiThreading"> the MultiThreading wiki page</a> for additional information. } newsitem {2006-01-10} {Version 3.3.0 alpha} { Version 3.3.0 adds support for CHECK constraints, DESC indices, separate REAL and INTEGER column affinities, a new OS interface layer |
︙ | ︙ | |||
1843 1844 1845 1846 1847 1848 1849 | open-source software. Thanks, AOL! Version 3.2.0 also fixes an obscure but serious bug that was discovered just prior to release. If you have a multi-statement transaction and within that transaction an UPDATE or INSERT statement fails due to a constraint, then you try to rollback the whole transaction, the rollback might not work correctly. See | | | | 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 | open-source software. Thanks, AOL! Version 3.2.0 also fixes an obscure but serious bug that was discovered just prior to release. If you have a multi-statement transaction and within that transaction an UPDATE or INSERT statement fails due to a constraint, then you try to rollback the whole transaction, the rollback might not work correctly. See <a href="https://www.sqlite.org/cvstrac/tktview?tn=1171">Ticket #1171</a> for details. Upgrading is recommended for all users. } newsitem {2005-03-16} {Version 3.1.6} { Version 3.1.6 fixes a critical bug that can cause database corruption when inserting rows into tables with around 125 columns. This bug was introduced in version 3.0.0. See <a href="https://www.sqlite.org/cvstrac/tktview?tn=1163">Ticket #1163</a> for additional information. } newsitem {2005-03-11} {Versions 3.1.4 and 3.1.5 Released} { Version 3.1.4 fixes a critical bug that could cause database corruption if the autovacuum mode of version 3.1.0 is turned on (it is off by default) and a CREATE UNIQUE INDEX is executed within a transaction but |
︙ | ︙ | |||
1878 1879 1880 1881 1882 1883 1884 | newsitem {2005-02-15} {Versions 2.8.16 and 3.1.2 Released} { A critical bug in the VACUUM command that can lead to database corruption has been fixed in both the 2.x branch and the main 3.x line. This bug has existed in all prior versions of SQLite. Even though it is unlikely you will ever encounter this bug, it is suggested that all users upgrade. See | | | | | | | | | 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 | newsitem {2005-02-15} {Versions 2.8.16 and 3.1.2 Released} { A critical bug in the VACUUM command that can lead to database corruption has been fixed in both the 2.x branch and the main 3.x line. This bug has existed in all prior versions of SQLite. Even though it is unlikely you will ever encounter this bug, it is suggested that all users upgrade. See <a href="https://www.sqlite.org/cvstrac/tktview?tn=1116"> ticket #1116</a>. for additional information. Version 3.1.2 is also the first stable release of the 3.1 series. SQLite 3.1 features added support for correlated subqueries, autovacuum, autoincrement, ALTER TABLE, and other enhancements. See the <a href="https://www.sqlite.org/releasenotes310.html">release notes for version 3.1.0</a> for a detailed description of the changes available in the 3.1 series. } newsitem {2005-02-01} {Version 3.1.1 (beta) Released} { Version 3.1.1 (beta) is now available on the website. Version 3.1.1 is fully backwards compatible with the 3.0 series and features many new features including Autovacuum and correlated subqueries. The <a href="https://www.sqlite.org/releasenotes310.html">release notes</a> From version 3.1.0 apply equally to this release beta. A stable release is expected within a couple of weeks. } newsitem {2005-01-21} {Version 3.1.0 (alpha) Released} { Version 3.1.0 (alpha) is now available on the website. Version 3.1.0 is fully backwards compatible with the 3.0 series and features many new features including Autovacuum and correlated subqueries. See the <a href="https://www.sqlite.org/releasenotes310.html">release notes</a> for details. This is an alpha release. A beta release is expected in about a week with the first stable release to follow after two more weeks. } newsitem {2004-11-09} {SQLite at the 2004 International PHP Conference} { There was a talk on the architecture of SQLite and how to optimize SQLite queries at the 2004 International PHP Conference in Frankfurt, Germany. <a href="https://www.sqlite.org/php2004/page-001.html"> Slides</a> from that talk are available. } newsitem {2004-10-11} {Version 3.0.8} { Version 3.0.8 of SQLite contains several code optimizations and minor bug fixes and adds support for DEFERRED, IMMEDIATE, and EXCLUSIVE transactions. This is an incremental release. There is no reason to upgrade from version 3.0.7 if that version is working for you. } newsitem {2004-10-10} {SQLite at the 11<sup><small>th</small></sup> Annual Tcl/Tk Conference} { There will be a talk on the use of SQLite in Tcl/Tk at the 11<sup><small>th</small></sup> Tcl/Tk Conference this week in New Orleans. Visit [https://www.tcl.tk/community/tcl2004/] for details. <a href="https://www.sqlite.org/tclconf2004/page-001.html"> Slides</a> from the talk are available. } newsitem {2004-09-18} {Version 3.0.7} { Version 3.0 has now been in use by multiple projects for several months with no major difficulties. We consider it stable and ready for production use. |
︙ | ︙ |
Changes to pages/opcode.in.
︙ | ︙ | |||
134 135 136 137 138 139 140 | <p> This article also uses the terms "bytecode program" and "prepared statement" interchangeably, as they are mostly the same thing. <h2>VDBE Source Code</h2> <p>The source code to the bytecode engine is in the | | | 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 | <p> This article also uses the terms "bytecode program" and "prepared statement" interchangeably, as they are mostly the same thing. <h2>VDBE Source Code</h2> <p>The source code to the bytecode engine is in the [https://www.sqlite.org/src/finfo?name=src/vdbe.c | vdbe.c] source file. The [opcode definitions] in this document are derived from comments in that source file. The source code comments are the canonical source of information about the bytecode engine. When in doubt, refer to the source code.</p> <p>In addition to the primary vdbe.c source code file, there are other helper code files in the source tree, all of whose names |
︙ | ︙ | |||
416 417 418 419 420 421 422 | All currently defined opcodes are described in the table below. This table was generated automatically by scanning the source code from the file <tcl> if {$uuid==""} { hd_puts "<b>vdbe.c</b>.\n" } else { | | | 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 | All currently defined opcodes are described in the table below. This table was generated automatically by scanning the source code from the file <tcl> if {$uuid==""} { hd_puts "<b>vdbe.c</b>.\n" } else { hd_puts "<a href=\"https://www.sqlite.org/src/artifact/$uuid\">vdbe.c</a>.\n" } </tcl> <p>Remember: The VDBE opcodes are <u>not</u> part of the interface definition for SQLite. The number of opcodes and their names and meanings change from one release of SQLite to the next. The opcodes shown in the table below are valid for SQLite |
︙ | ︙ |
Changes to pages/pragma.in.
︙ | ︙ | |||
243 244 245 246 247 248 249 | unsigned big-endian "Application ID" integer located at offset 68 into the [database header]. Applications that use SQLite as their [application file-format] should set the Application ID integer to a unique integer so that utilities such as [http://www.darwinsys.com/file/ | file(1)] can determine the specific file type rather than just reporting "SQLite3 Database". A list of assigned application IDs can be seen by consulting the | | | 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 | unsigned big-endian "Application ID" integer located at offset 68 into the [database header]. Applications that use SQLite as their [application file-format] should set the Application ID integer to a unique integer so that utilities such as [http://www.darwinsys.com/file/ | file(1)] can determine the specific file type rather than just reporting "SQLite3 Database". A list of assigned application IDs can be seen by consulting the [https://www.sqlite.org/src/artifact?ci=trunk&filename=magic.txt |magic.txt] file in the SQLite source repository. <p> See also the [user_version pragma]. } Pragma {automatic_index} { <p>^(<b>PRAGMA automatic_index; |
︙ | ︙ |
Changes to pages/privatebranch.in.
︙ | ︙ | |||
37 38 39 40 41 42 43 | circumstances of each individual project.</p> <img src="images/private_branch.gif" align="right"> <h1> The Basic Idea</h1> <p>We propose to use the | | | | 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 | circumstances of each individual project.</p> <img src="images/private_branch.gif" align="right"> <h1> The Basic Idea</h1> <p>We propose to use the [https://www.fossil-scm.org | fossil software configuration management] system to set up two branches. One branch (the "public branch" or "trunk") contains the published SQLite sources and the other branch is the private branch which contains the code that is customized for the project. Whenever a new public release of SQLite is made, that release is added to the public branch and then the changes are merged into the private branch.</p> <p>This document proposes to use [https://www.fossil-scm.org/ | fossil], but any other distributed software configuration management system such as [http://www.monotone.ca/ | monotone] or [http://www.selenic.com/mercurial/wiki/ | mercurial] (a.k.a. "hg"), or [http://www.git-scm.org/ | git] could serve just as well. The concept will be the same, though the specifics of the procedure will vary.</p> |
︙ | ︙ | |||
100 101 102 103 104 105 106 | <p>We emphasize again that these steps are not intended to be the only acceptable method for maintaining private branch. This approach is one of many. Use this document as a baseline for preparing project-specific procedures. Do not be afraid to experiment.</p> <h2> Obtain The Software</h2> | | | | | 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 | <p>We emphasize again that these steps are not intended to be the only acceptable method for maintaining private branch. This approach is one of many. Use this document as a baseline for preparing project-specific procedures. Do not be afraid to experiment.</p> <h2> Obtain The Software</h2> <p>[https://www.fossil-scm.org/ | Fossil] is a computer program that must be installed on your machine before you use it. Fortunately, installing fossil is very easy. Fossil is a single "*.exe" file that you simply download and run. To uninstall fossil, simply delete the exe file. [https://www.fossil-scm.org/index.html/doc/tip/www/quickstart.wiki | Detailed instructions] for installing and getting started with fossil are available on the [https://www.fossil-scm.org | fossil website].</p> <h2> Create A Project Repository</h2> <p>Create a fossil repository to host the private branch using the following command:</p> <blockquote><pre> |
︙ | ︙ | |||
345 346 347 348 349 350 351 | Additional private changes can be made on the private branch in between releases if desired.</p> <h1> Variations</h1> <p>Since this document was first written, the canonical SQLite source code has been moved from the venerable CVS system into a Fossil repository at | | | | 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 | Additional private changes can be made on the private branch in between releases if desired.</p> <h1> Variations</h1> <p>Since this document was first written, the canonical SQLite source code has been moved from the venerable CVS system into a Fossil repository at [https://www.sqlite.org/src]. This means that if you are working with canonical SQLite source code (as opposed to the [amalgamation] source code files, sqlite3.c and sqlite3.h) then you can create a private repository simply by cloning the official repository:</p> <blockquote><pre> fossil clone https://www.sqlite.org/src private-project.fossil </pre></blockquote> <p>This command both creates the new repository and populates it with all the latest SQLite code. You can then create a private branch as described in section 3.4.</p> <p>When the private repository is created by cloning, incorporating new |
︙ | ︙ |
Changes to pages/queryplanner-ng.in.
︙ | ︙ | |||
390 391 392 393 394 395 396 | <p>Not all applications meet these conditions. Fortunately, the NGQP will still usually find good query plans, even without these conditions. However, cases do arise (rarely) where performance regressions can occur.</p> <tcl>hd_fragment fossilcasestudy {The Fossil NGQP Upgrade Case Study}</tcl> <h2> Case Study: Upgrading Fossil to the NGQP</h2> | | | | 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 | <p>Not all applications meet these conditions. Fortunately, the NGQP will still usually find good query plans, even without these conditions. However, cases do arise (rarely) where performance regressions can occur.</p> <tcl>hd_fragment fossilcasestudy {The Fossil NGQP Upgrade Case Study}</tcl> <h2> Case Study: Upgrading Fossil to the NGQP</h2> <p>The <a href="https://www.fossil-scm.org/">Fossil DVCS</a> is the version control system used to track all of the SQLite source code. A Fossil repository is an SQLite database file. (Readers are invited to ponder this recursion as an independent exercise.) Fossil is both the version-control system for SQLite and a test platform for SQLite. Whenever enhancements are made to SQLite, Fossil is one of the first applications to test and evaluate those enhancements. So Fossil was an early adopter of the NGQP.</p> <p>Unfortunately, the NGQP caused a performance regression in Fossil.</p> <p>One of the many reports that Fossil makes available is a timeline of changes to a single branch showing all merges in and out of that branch. See <a href="https://www.sqlite.org/src/timeline?nd&n=200&r=trunk">https://www.sqlite.org/src/timeline?nd&n=200&r=trunk</a> for a typical example of such a report. Generating such a report normally takes just a few milliseconds. But after upgrading to the NGQP we noticed that this one report was taking closer to 10 seconds for the trunk of the repository.</p> <p>The core query used to generate the branch timeline is shown below. |
︙ | ︙ |
Changes to pages/quickstart.in.
︙ | ︙ | |||
23 24 25 26 27 28 29 | <li><p>Additional documentation is available [CLI | here].</li> </ul> <h2>Write Programs That Use SQLite</h2> <ul> <li><p>Below is a simple | | | 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 | <li><p>Additional documentation is available [CLI | here].</li> </ul> <h2>Write Programs That Use SQLite</h2> <ul> <li><p>Below is a simple [https://www.tcl.tk | TCL program] that demonstrates how to use the TCL interface to SQLite. The program executes the SQL statements given as the second argument on the database defined by the first argument. The commands to watch for are the <b>sqlite3</b> command on line 7 which opens an SQLite database and creates a new object named "<b>db</b>" to access that database, the use of the [eval method] on the <b>db</b> object on line 8 to run SQL commands against the database, and the closing of the database connection |
︙ | ︙ |
Changes to pages/spellfix1.in.
︙ | ︙ | |||
10 11 12 13 14 15 16 | can be used to suggest corrections to misspelled words. Or, it could be used with [FTS4] to do full-text search using potentially misspelled words. <p>The implementation for the spellfix1 virtual table is held in the SQLite source tree in the miscellaneous extensions folder and in particular in the file | | | 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | can be used to suggest corrections to misspelled words. Or, it could be used with [FTS4] to do full-text search using potentially misspelled words. <p>The implementation for the spellfix1 virtual table is held in the SQLite source tree in the miscellaneous extensions folder and in particular in the file [https://www.sqlite.org/src/finfo?name=ext/misc/spellfix.c|ext/misc/spellfix1.c]. The spellfix1 virtual table is not included in the SQLite [amalgamation] and is not a part of any standard SQLite build. It is a [loadable extension]. <p>Once the spellfix1 extension is loaded, an instance of the spellfix1 virtual table is created like this: <blockquote><pre> |
︙ | ︙ |
Changes to pages/tclsqlite.in.
1 2 3 4 5 6 7 8 9 10 11 12 13 | <title>The Tcl interface to the SQLite library</title> <tcl> hd_keywords {Tcl extension} {TCL Interface} proc METHOD {name text} { hd_fragment $name [list $name method] [list TCL interface $name method] hd_puts "<h3>The \"$name\" method</h3>\n" hd_resolve $text } </tcl> <h1 align=center>The Tcl interface to the SQLite library</h1> <p>The SQLite library is designed to be very easy to use from | | | | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | <title>The Tcl interface to the SQLite library</title> <tcl> hd_keywords {Tcl extension} {TCL Interface} proc METHOD {name text} { hd_fragment $name [list $name method] [list TCL interface $name method] hd_puts "<h3>The \"$name\" method</h3>\n" hd_resolve $text } </tcl> <h1 align=center>The Tcl interface to the SQLite library</h1> <p>The SQLite library is designed to be very easy to use from a [https://www.tcl.tk | Tcl or Tcl/Tk] script. SQLite began as a [https://www.tcl.tk/doc/tea/ | Tcl extension] and the primary [test suite] for SQLite is written in TCL. SQLite can be used with any programming language, but its connections to TCL run deep.</p> <p>This document gives an overview of the Tcl programming interface for SQLite.</p> |
︙ | ︙ |
Changes to pages/testing.in.
︙ | ︙ | |||
152 153 154 155 156 157 158 | <li><p> <tcl>hd_fragment tcl {TCL test suite}</tcl> The <b>TCL Tests</b> are the oldest set of tests for SQLite. They are contained in the same source tree as the SQLite core and like the SQLite core are in the public domain. The TCL tests are the primary tests used during development. The TCL tests are written using the | | | 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 | <li><p> <tcl>hd_fragment tcl {TCL test suite}</tcl> The <b>TCL Tests</b> are the oldest set of tests for SQLite. They are contained in the same source tree as the SQLite core and like the SQLite core are in the public domain. The TCL tests are the primary tests used during development. The TCL tests are written using the [https://www.tcl.tk/ | TCL scripting language]. The TCL test harness itself consists of <tcl>KB {$stat(tclcSLOC)}</tcl> KSLOC of C code used to create the TCL interface. The test scripts are contained in <tcl>N {$stat(tclsNFile)}</tcl> files totaling <tcl>MiB {$stat(tclsNByte)}</tcl>MB in size. There are <tcl>N {$stat(tclNTest)}</tcl> distinct test cases, but many of the test cases are parameterized and run multiple times (with different parameters) so that on a full test run millions of |
︙ | ︙ | |||
183 184 185 186 187 188 189 | instances. The cases that provide 100% branch test coverage constitute a subset of the total TH3 test suite. A soak test prior to release does hundreds of millions of tests. Additional information on TH3 is [TH3 | available separately].</p></li> <li><p> <tcl>hd_fragment slt {SLT} {SQL Logic Tests}</tcl> | | | 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 | instances. The cases that provide 100% branch test coverage constitute a subset of the total TH3 test suite. A soak test prior to release does hundreds of millions of tests. Additional information on TH3 is [TH3 | available separately].</p></li> <li><p> <tcl>hd_fragment slt {SLT} {SQL Logic Tests}</tcl> The <a href="https://www.sqlite.org/sqllogictest"><b>SQL Logic Test</b></a> or SLT test harness is used to run huge numbers of SQL statements against both SQLite and several other SQL database engines and verify that they all get the same answers. SLT currently compares SQLite against PostgreSQL, MySQL, Microsoft SQL Server, and Oracle 10g. SLT runs <tcl>MB {$stat(sltNTest)}</tcl> million queries comprising <tcl>GB {$stat(sltsNByte)}</tcl>GB of test data. </p></li> |
︙ | ︙ | |||
962 963 964 965 966 967 968 | <tcl>hd_fragment cklist {release testing checklists} {checklist}</tcl> <h1>Checklists</h1> <p>The SQLite developers use an on-line checklist to coordinate testing activity and to verify that all tests pass prior each SQLite release. | | | 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 | <tcl>hd_fragment cklist {release testing checklists} {checklist}</tcl> <h1>Checklists</h1> <p>The SQLite developers use an on-line checklist to coordinate testing activity and to verify that all tests pass prior each SQLite release. <a href="https://www.sqlite.org/checklists/index.html">Past checklists</a> are retained for historical reference. (The checklists are read-only for anonymous internet viewers, but developers can log in and update checklist items in their web browsers.) The use of checklists for SQLite testing and other development activities is inspired by <i> [http://atulgawande.com/book/the-checklist-manifesto/ | The Checklist Manifesto] |
︙ | ︙ |
Changes to pages/th3.in.
︙ | ︙ | |||
49 50 51 52 53 54 55 | to remedy this problem was the "TH1" (Test Harness #1) scripting language - a reimplementation of parts of the TCL language in a more portable form that would compile and run on SymbianOS, and that was sufficient to run the SQLite tests. TH1 did not survive as a standard testing tool for SQLite, but it did find continued service as a scripting language used to customize the | | | 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 | to remedy this problem was the "TH1" (Test Harness #1) scripting language - a reimplementation of parts of the TCL language in a more portable form that would compile and run on SymbianOS, and that was sufficient to run the SQLite tests. TH1 did not survive as a standard testing tool for SQLite, but it did find continued service as a scripting language used to customize the [https://www.fossil-scm.org/|Fossil] version control system. There was also a "Test Harness #2" which was an attempt to create a simple scripting language using operator prefix notation to drive tests. TH3 was the third attempt. <p>At about that same time, some avionics manufacturers were expressing interest in SQLite, which prompted the SQLite developers to design TH3 to support the rigorous testing standards of |
︙ | ︙ |
Changes to pages/undoredo.in.
︙ | ︙ | |||
82 83 84 85 86 87 88 | <p> Triggers such as the above could be entered manually, but that is tedious. An important feature of the technique demonstrated below is that the triggers are generated automatically. <p> The implementation language for the example code is | | | 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 | <p> Triggers such as the above could be entered manually, but that is tedious. An important feature of the technique demonstrated below is that the triggers are generated automatically. <p> The implementation language for the example code is [https://www.tcl.tk|TCL], though you can easily do the same thing in another programming language. Remember that the code here is a demonstration of the technique, not a drop-in module that will automatically do everything for you. The demonstration code shown below is derived from actual code in production use. But you will need to make changes to tailor it to your application. |
︙ | ︙ |
Changes to pages/version3.in.
︙ | ︙ | |||
95 96 97 98 99 100 101 | These changes taken together result in database files that are typically 25% to 35% smaller than the equivalent files in SQLite version 2.8. </p> <p> Details of the low-level B-tree format used in SQLite version 3.0 can be found in header comments to the | | | 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 | These changes taken together result in database files that are typically 25% to 35% smaller than the equivalent files in SQLite version 2.8. </p> <p> Details of the low-level B-tree format used in SQLite version 3.0 can be found in header comments to the <a href="https://www.sqlite.org/src/finfo?name=src/btreeInt.h">btreeInt.h</a> source file and in the [file format] documentation. </p> <h3>Manifest Typing and BLOB Support</h3> <p> SQLite version 2.8 will deal with data in various formats internally, |
︙ | ︙ |
Changes to pages/vfs.in.
︙ | ︙ | |||
92 93 94 95 96 97 98 | VXWorks only. </ol> <p> The various unix VFSes differ only in the way they handle file locking - they share most of their implementation in common with one another and are all located in the same SQLite source file: | | | 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 | VXWorks only. </ol> <p> The various unix VFSes differ only in the way they handle file locking - they share most of their implementation in common with one another and are all located in the same SQLite source file: [https://www.sqlite.org/src/doc/trunk/src/os_unix.c | os_unix.c]. Note that except for "unix" and "unix-excl", the various unix VFSes all use incompatible locking implementations. If two processes are accessing the same SQLite database using different unix VFSes, they may not see each others locks and may end up interfering with one another, resulting in database corruption. The "unix-none" VFS in particular does no locking at all and will easily result in database corruption if used by two or more database connections at the same time. |
︙ | ︙ | |||
186 187 188 189 190 191 192 | just be a thin wrapper around another VFS that does the real work. We call a wrapper VFS a "shim". </p> <p> A simple example of a shim is the "vfstrace" VFS. This is a VFS (implemented in the | | | | | | | | | | 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 | just be a thin wrapper around another VFS that does the real work. We call a wrapper VFS a "shim". </p> <p> A simple example of a shim is the "vfstrace" VFS. This is a VFS (implemented in the [https://www.sqlite.org/src/doc/trunk/src/test_vfstrace.c | test_vfstrace.c] source file) that writes a message associated with each VFS method call into a log file, then passes control off to another VFS to do the actual work. </p> <h2>Other Example VFSes</h2> <p> The following are other VFS implementations available in the public SQLite source tree: </p> <ul> <li><p> [https://www.sqlite.org/src/file/ext/misc/appendvfs.c | appendvfs.c] - This VFS allows an SQLite database to be appended to the end of some other file. This can be used, for example, to append an SQLite database onto the end of an executable such that the executable where it can then be easily located by the executable when needed. The [command-line shell] will use this VFS if launched with the --append option. <li><p> [https://www.sqlite.org/src/doc/trunk/src/test_demovfs.c | test_demovfs.c] - This file implements a very simple VFS named "demo" that uses POSIX functions such as open(), read(), write(), fsync(), close(), fsync(), sleep(), time(), and so forth. This VFS only works on unix systems. But it is not intended as a replacement for the standard "unix" VFS used by default on unix platforms. The "demo" VFS is deliberately kept very simple so that it can be used as a learning aid or as template for building other VFSes or for porting SQLite to new operating systems. <li><p> [https://www.sqlite.org/src/doc/trunk/src/test_quota.c | test_quota.c] - This file implements a shim called "quota" that enforces cumulative file size limits on a collection of database files. An auxiliary interface is used to define "quota groups". A quota group is a set of files (database files, journals, and temporary files) whose names all match a [GLOB] pattern. The sum of the sizes of all files in each quota group is tracked, and if that sum exceeds a threshold defined for the quota group, a callback function is invoked. That callback can either increase the threshold or cause the operation that would have exceeded the quota to fail with an [SQLITE_FULL] error. One of the uses of this shim is used to enforce resource limits on application databases in Firefox. <li><p> [https://www.sqlite.org/src/doc/trunk/src/test_multiplex.c | test_multiplex.c] - This file implements a shim that allows database files to exceed the maximum file size of the underlying filesystem. This shim presents an interface to the upper six layers of SQLite that makes it look like very large files are being used, when in reality each such large file is split up into many smaller files on the underlying system. This shim has been used, for example, to allow databases to grow larger than 2 gibibytes on FAT16 filesystems. <li><p> [https://www.sqlite.org/src/doc/trunk/src/test_onefile.c | test_onefile.c] - This file implements a demonstration VFS named "fs" that shows how SQLite can be used on an embedded device that lacks a filesystem. Content is written directly to the underlying media. A VFS derived from this demonstration code could be used by a gadget with a limited amount of flash memory to make SQLite behave as the filesystem for the flash memory on the device. <li><p> [https://www.sqlite.org/src/doc/trunk/src/test_journal.c | test_journal.c] - This file implements a shim used during SQLite testing that verifies that the database and rollback journal are written in the correct order and are "synced" at appropriate times in order to guarantee that the database can recover from a power lose are hard reset at any time. The shim checks several invariants on the operation of databases and rollback journals and raises exceptions if any of those invariants are violated. These invariants, in turn, assure that the database is always recoverable. Running a large suite of test cases using this shim provides added assurance that SQLite databases will not be damaged by unexpected power failures or device resets. <li><p> [https://www.sqlite.org/src/doc/trunk/src/test_vfs.c | test_vfs.c] - This file implements a shim that can be used to simulate filesystem faults. This shim is used during testing to verify that SQLite responses sanely to hardware malfunctions or to other error conditions such as running out of filesystem space that are difficult to test on a real system. </ul> <p> |
︙ | ︙ |
Changes to pages/vtab.in.
︙ | ︙ | |||
478 479 480 481 482 483 484 | <p>A [virtual table] that contains [hidden columns] can be used like a table-valued function in the FROM clause of a [SELECT] statement. The arguments to the table-valued function become constraints on the HIDDEN columns of the virtual table. <p>For example, the "generate_series" extension (located in the | | | | 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 | <p>A [virtual table] that contains [hidden columns] can be used like a table-valued function in the FROM clause of a [SELECT] statement. The arguments to the table-valued function become constraints on the HIDDEN columns of the virtual table. <p>For example, the "generate_series" extension (located in the [https://www.sqlite.org/src/artifact?ci=trunk&filename=ext/misc/series.c|ext/misc/series.c] file in the [https://www.sqlite.org/src/tree?ci=trunk|source tree]) implements an [eponymous virtual table] with the following schema: <codeblock> CREATE TABLE generate_series( value, start HIDDEN, stop HIDDEN, |
︙ | ︙ |
Changes to pages/withoutrowid.in.
︙ | ︙ | |||
238 239 240 241 242 243 244 | tables are implemented using ordinary B-Trees with content stored on both leaves and intermediate nodes. Storing content in intermediate nodes mean that each intermediate node entry takes up more space on the page and thus reduces the fan-out, increasing the search cost. <p>The "sqlite3_analyzer.exe" utility program, available as source code in the SQLite source tree or as a precompiled binary on the | | | 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 | tables are implemented using ordinary B-Trees with content stored on both leaves and intermediate nodes. Storing content in intermediate nodes mean that each intermediate node entry takes up more space on the page and thus reduces the fan-out, increasing the search cost. <p>The "sqlite3_analyzer.exe" utility program, available as source code in the SQLite source tree or as a precompiled binary on the [https://www.sqlite.org/download.html | SQLite Download page], can be used to measure the average sizes of table rows in an existing SQLite database.</p> <p>Note that except for a few corner-case differences detailed above, WITHOUT ROWID tables and rowid tables work the same. They both generate the same answers given the same SQL statements. So it is a simple matter to run experiments on an application, late in the development cycle, |
︙ | ︙ |