SQLite (64-bit)

What's new in this version:

- Fix a potential memory leak in the new sqlite3_result_pointer() interface.

Changes carried forward from version 3.20.0:
- Update the text of error messages returned by sqlite3_errmsg() for some error codes
- Add new pointer passing interfaces
- Backwards-incompatible changes to some extensions in order to take advantage of the improved security offered by the new pointer passing interfaces: a. Extending FTS5 → requires sqlite3_bind_pointer() to find the fts5_api pointer
- carray(PTR,N) → requires sqlite3_bind_pointer() to set the PTR parameter
- remember(V,PTR) → requires sqlite3_bind_pointer() to set the PTR parameter
- Added the SQLITE_STMT virtual table extension
- Added the COMPLETION extension - designed to suggest tab-completions for interactive user interfaces. This is a work in progress. Expect further enhancements in future releases
- Added the UNION virtual table extension
- The built-in date and time functions have been enhanced so that they can be used in CHECK constraints, in indexes on expressions, and in the WHERE clauses of partial indexes, provided that they do not use the 'now', 'localtime', or 'utc' keywords. Futher information
- Added the sqlite3_prepare_v3() and sqlite3_prepare16_v3() interfaces with the extra "prepFlags" parameters
- Provide the SQLITE_PREPARE_PERSISTENT flag for sqlite3_prepare_v3() and use it to limit lookaside memory misuse by FTS3, FTS5, and the R-Tree extension
- Added the PRAGMA secure_delete=FAST command. When secure_delete is set to FAST, old content is overwritten with zeros as long as that does not increase the amount of I/O. Deleted content might still persist on the free-page list but will be purged from all b-tree pages
- Enhancements to the command-line shell: a. Add support for tab-completion using the COMPLETION extension, for both readline and linenoise
- Add the ".cd" command
- Enhance the ".schema" command to show the schema of all attached databases
- Enhance ".tables" so that it shows the schema names for all attached if the name is anything other than "main"
- The ".import" command ignores an initial UTF-8 BOM
- Added the "--newlines" option to the ".dump" command to cause U+000a and U+000d characters to be output literally rather than escaped using the replace() function
- Query planner enhancements: a. When generating individual loops for each ORed term of an OR scan, move any constant WHERE expressions outside of the loop, as is done for top-level loops
- The query planner examines the values of bound parameters to help determine if a partial index is usable
- When deciding between two plans with the same estimated cost, bias the selection toward the one that does not use the sorter
- Evaluate WHERE clause constraints involving correlated subqueries last, in the hope that they never have be evaluated at all
- Do not use the flattening optimization for a sub-query on the RHS of a LEFT JOIN if that subquery reads data from a virtual table as doing so prevents the query planner from creating automatic indexes on the results of the sub-query, which can slow down the query
- Add SQLITE_STMTSTATUS_REPREPARE, SQLITE_STMTSTATUS_RUN, and SQLITE_STMTSTATUS_MEMUSED options for the sqlite3_stmt_status() interface
- Provide PRAGMA functions for PRAGMA integrity_check, PRAGMA quick_check, and PRAGMA foreign_key_check
- Add the -withoutnulls option to the TCL interface eval method
- Enhance the sqlite3_analyzer.exe utility program so that it shows the number of bytes of metadata on btree pages
- The SQLITE_DBCONFIG_ENABLE_QPSG run-time option and the SQLITE_ENABLE_QPSG compile-time option enable the query planner stability guarantee
- Miscellaneous optimizations result in a 2% reduction in CPU cycles used

Bug Fixes:
- Fix the behavior of sqlite3_column_name() for queries that use the flattening optimization so that the result is consistent with other queries that do not use that optimization, and with PostgreSQL, MySQL, and SQLServer
- Fix the query planner so that it knows not to use automatic indexes on the right table of LEFT JOIN if the WHERE clause uses the IS operator
- Ensure that the query planner knows that any column of a flattened LEFT JOIN can be NULL even if that column is labeled with "NOT NULL"
- Fix rare false-positives in PRAGMA integrity_check when run on a database connection with attached databases
- Fix a bug (discovered by OSSFuzz) that causes an assertion fault if certain dodgy CREATE TABLE declarations are used