Enhance the "PRAGMA index_info" and "PRAGMA index_xinfo" statements so that
they work on WITHOUT ROWID tables and provide information about the underlying
index btree that implements the WITHOUT ROWID table.
(Leaf
check-in: fe49fb03 user: drh tags: index-info-on-table)

In the sessions module, avoid recording a change if an UPDATE statement
overwrites a column with REAL affinity containing an integer value with
the same value.
(check-in: 5f3e6028 user: drh tags: trunk)

In the sessions module, avoid recording a change if an UPDATE statement
overwrites a column with REAL affinity containing an integer value with the same value.
(Closed-Leaf
check-in: b861328a user: dan tags: sessions-fix)

Avoid using the "direct overflow read" optimization to read large blobs if the
pager layer has a wal file open - even if the database header indicates that
the db is not a wal database.
(check-in: b54c15f1 user: dan tags: trunk)

Avoid reading the -1-th element of an array in the query planner. Fix to a
bug introduced by check-in [8e2b25f9b8a7] from earlier today. Curiously,
the problem only appeared on 32-bit systems.
(check-in: 443913d5 user: drh tags: trunk)

Avoid initializing the column-cache section of the Parse object, since entries
in the cache will be initialized as they are used, and avoiding the initial
memset() saves many CPU cycles.
(check-in: 63cf7eaf user: drh tags: trunk)

Remove the peep-hole optimization of removing OP_Close opcodes that come
before OP_Halt, as the extra work of removing those opcodes uses more cycles
than just running them.
(check-in: 984a96d7 user: drh tags: trunk)

When flattening a query of the form "SELECT * FROM (SELECT * FROM tbl WHERE x=?) WHERE y=?", ensure that the final WHERE clause is "x=? AND y=?" instead of "y=? AND x=?". Although it is still not guaranteed, this makes the order in which WHERE clause terms are processed comport more closely to users expectations.
(check-in: cf7f9e6d user: dan tags: trunk)

Fix a potential null-pointer dereference and crash in the case where one
thread is calling sqlite3_column_text() and another thread is calling
sqlite3_step() on the same prepared statement at the same instant.
(check-in: ee1382a3 user: drh tags: trunk)