Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.
5 check-ins occurring around 787c76a865dc51db.
|11:12||Fix a problem handling ORDER BY terms of the form "ORDER BY likely(<integer>)" within window frames. (check-in: 710f75b9 user: dan tags: trunk)|
|23:30||This is another alternative fix to the covering index on WHERE_MULTI_OR in a LEFT JOIN problem that is fixed on trunk nearby. In this alternative, covering indexes are simply disabled for WHERE_MULTI_OR on a LEFT JOIN. This might have run-time impact on some obscure queries. This patch is saved for historical reference only. (Closed-Leaf check-in: 66856410 user: drh tags: multi-or-covidx-fix3)|
|23:27||This is an alternative fix to the covering index on WHERE_MULTI_OR in a LEFT JOIN problem that is fixed nearby. This one works by having the OP_NullRow opcode create the index if it does not already exist. That is slightly more complex. This patch is saved for historical reference only. (Closed-Leaf check-in: 956bafb6 user: drh tags: multi-or-covidx-fix2)|
|23:24||When an index is used by all branches of the WHERE_MULTI_OR optimization and becomes a covering index, make sure the index has been created prior to NULLing it in the OP_NullRow opcode of a LEFT JOIN. See forum post 0575376e07. The covering-index for WHERE_MULTI_OR optimization was added by [62678be3df35cdcb]. Test cases are in the orindex01.test module of TH3. (check-in: 787c76a8 user: drh tags: trunk)|
|18:32||Add the sqlite3_changes64() and sqlite3_total_changes64() API functions. (check-in: 48fdec22 user: dan tags: trunk)|