*** DRAFT ***

SQLite Release 3.24.0 On 2018-06-04

  1. Add support for PostgreSQL-style UPSERT.
  2. Add support for auxiliary columns in r-tree tables.
  3. Add C-language APIs for discovering SQL keywords used by SQLite: sqlite3_keyword_count(), sqlite3_keyword_name(), and sqlite3_keyword_check().
  4. Add C-language APIs for dynamic strings based on the sqlite3_str object.
  5. Enhance ALTER TABLE so that it recognizes "true" and "false" as valid arguments to DEFAULT.
  6. Add the sorter-reference optimization as a compile-time option. Only available if compiled with SQLITE_ENABLE_SORTER_REFERENCES.
  7. Improve the format of the EXPLAIN QUERY PLAN raw output, so that it gives better information about the query plan and about the relationships between the various components of the plan.
  8. Added the SQLITE_DBCONFIG_RESET_DATABASE option to the sqlite3_db_config() API.

    CLI Enhancements:

  9. Automatically intercepts the raw EXPLAIN QUERY PLAN output and reformats it into an ASCII-art graph.
  10. Lines that begin with "#" and that are not in the middle of an SQL statement are interpreted as comments.
  11. Added the --append option to the ".backup" command.
  12. Added the ".dbconfig" command.

    Performance:

  13. UPDATE avoids unnecessary low-level disk writes when the contents of the database file do not actually change. For example, "UPDATE t1 SET x=25 WHERE y=?" generates no extra disk I/O if the value in column x is already 25. Similarly, when doing UPDATE on records that span multiple pages, only the subset of pages that actually change are written to disk. This is a low-level performance optimization only and does not affect the behavior of TRIGGERs or other higher level SQL structures.
  14. Queries that use ORDER BY and LIMIT now try to avoid computing rows that cannot possibly come in under the LIMIT. This can greatly improve performance of ORDER BY LIMIT queries, especially when the LIMIT is small relative to the number of unrestricted output rows.
  15. The OR optimization is allowed to proceed even if the OR expression has also been converted into an IN expression. Uses of the OR optimization are now also more clearly shown in the EXPLAIN QUERY PLAN output.
  16. The query planner is more aggressive about using automatic indexes for views and subqueries for which it is not possible to create a persistent index.
  17. Make use of the one-pass UPDATE and DELETE query plans in the R-Tree extension where appropriate.
  18. Performance improvements in the LEMON-generated parser.

    Bug fixes:

  19. For the right-hand table of a LEFT JOIN, compute the values of expressions directly rather than loading precomputed values out of an expression index as the expression index might not contain the correct value. Ticket 7fa8049685b50b5aeb0c2
  20. Do not attempt to use terms from the WHERE clause to enable indexed lookup of the right-hand table of a LEFT JOIN. Ticket 4ba5abf65c5b0f9a96a7a
  21. Fix a memory leak that can occur following a failure to open error in the CSV virtual table
  22. Fix a long-standing problem wherein a corrupt schema on the sqlite_sequence table used by AUTOINCREMENT can lead to a crash. Ticket d8dc2b3a58cd5dc2918a1
  23. Fix the json_each() function so that it returns valid results on its "fullkey" column when the input is a simple value rather than an array or object.

    Hashes:

  24. SQLITE_SOURCE_ID: "2018-06-04 19:24:41 c7ee0833225bfd8c5ec2f9bf62b97c4e04d03bd9566366d5221ac8fb199a87ca"
  25. SHA3-256 for sqlite3.c: 0d384704e1c66026228336d1e91771d295bf688c9c44c7a44f25a4c16c26ab3c

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 SQLite version control site.

*** DRAFT ***