during an UPDATE to modify the the table being updated. Otherwise, those
triggers might delete content out from under the update operation, leading
to all kinds of problems. Ticket [314cc133e5ada126]
FossilOrigin-Name: db4b7e1dc399c1f16b827ac087aa37c0815f4b2f41f1ffad59963eead2ab5562
has not already completed. Also add the sqlite3WhereUsesDeferredSeek()
interface to the query planner. The UPDATE implementation adds an
OP_FinishSeek before running the final OP_Insert if one is needed.
Ticket [ec8abb025e78f40c] and also an assertion fault reported by Yongheng.
FossilOrigin-Name: 21ef6e99331210b80fa7c71b4f02e8f768a748d01aef884368af2f6b51a067e0
at the top of each iteration of the loop in order to prevent spurious
OP_SCopy misuse complaints. Ticket [de4b04149b9fdeae]
FossilOrigin-Name: 6afadd3b3a40b0ef29fd14fb24c2a4b9479483e5f8b9125ce02d8daae662207f
NOT NULL ON CONFLICT REPLACE constraints fire.
Tickets [37823501c68a09f9] and [5fbc159eeb092130].
FossilOrigin-Name: 4cc12c18860bc4801a407cf45e88e23d3d40391f01a461fbac2cac5f102100e1
the write lock, even when transitioning from EXCLUSIVE locking mode into
NORMAL locking mode while in WAL mode. Ticket [fb3b3024ea238d5c].
FossilOrigin-Name: 846b1de6e5a9e418f225273dc033234c64c116fcd89c8261522b4902c248451f
or NULL filename in the ZIP archive. But report on the mailing list by
Yongheng and Rui.
FossilOrigin-Name: 465a15c5c2077011befa854a77f9d295bb751ef20b7d2937ac0ba47cc84587c9
the one-pass optimization might cause the table seek to be omitted before
reaching row DELETE/INSERT. Fix this by coding an extra OP_Column in that
circumstance. Ticket [ec8abb025e78f40c]
FossilOrigin-Name: e54560495926fbb8a2ce829c677a2dd0066e46b7a8d4ada9d8a34a3426959836
the SELECT statement into just "SELECT null" so that it does not leave the
parse tree in a goofy state that can cause problems with subsequent code
before the stack has a chance to unwind and report the error.
Ticket [d87336c81c7d0873]
FossilOrigin-Name: fa58aad48a788802b13a819e49f9b8787f713bbe395c46c7295e821c52c81738
Rui have found a test case for which it fails. The new test case is added
to fuzzcheck.
FossilOrigin-Name: ddb10f0374e66886d0681937b14cf0b4f100f03d3955b45b6c508dc6d9e36976
by adding the new OP_ReleaseReg opcode to tell MemAboutToChange() that a
range of registers is no longer needed so that the source register can be
freely changed. This is a change to debugging and test builds only and
does not impact release builds. Fix for ticket
[c62c5e58524b204d] and [5ad2aa6921faa1ee]. The previous fix to ticket
[5ad2aa6921faa1ee] is backed out by this change since this change is a better
fix.
FossilOrigin-Name: 36fdeb4f0a66970a35de688b617f90899c89cfdfab659f864df99aa7ebf854ea
OP_RealAffinity, to avoid problems with a pointer accounting assert.
This change is not strictly necessary - the correct answer is obtained
without it and no UB occurs - however the pointer accounting asserts are
useful to prevent other problems so it is a simple matter to bring this
piece into compliance. Ticket [5ad2aa6921faa1ee]
FossilOrigin-Name: 89a9dad6330270a4c3b962f86a208088d2ea9883c7d291351a77f058e0ed8b0c
table that is in a LEFT JOIN, be sure to set the correct Expr.iRightJoinTable
value. This value does not appear to ever be used, except inside of a single
assert(). But it is good to set it correctly, nevertheless. This fixes
ticket [7929c1efb2d67e98], which as far as I can tell is completely harmless.
FossilOrigin-Name: ef604882a275d3d5ebd4d5a08e3fe43e148f169b7d5c3a81464fbe7f54f3582a
constraints if there are any errors, since there might otherwise be attempts
to use those CHECK constraints if PRAGMA writable_schema=ON is set.
This undoes the fix in check-in [ea721b34477ab8b4] for a more general
solution.
FossilOrigin-Name: a982e6434cd66bfbe94d455f538bcbc4360b91572062d92acae6b77e9560e65d
processes the correct entry in the sqlite_master table even if there is
a second entry with the same name and table values due to database corruption
and the use of writable_schema=ON. Dbsqlfuzz find.
FossilOrigin-Name: 4dbb6e1cb094f3428c74ea8bdd86ab63341fecce978a062968ca01423f382e90
(or other expressions in the table definition) might not be fully resolved.
Ensure that the code generator can deal with this if the table is subsequently
used in a DML statement. dbsqlfuzz find.
FossilOrigin-Name: ea721b34477ab8b49d182352c4bc198245933b850e9b6248b4f97600e80bb44b
sequence for the generated column is non-standard.
Part 2 of ticket [e0a8120553f4b082]
FossilOrigin-Name: 056bb8dcbdc45989c5c6e86d2966200062e3c01c382ec52aae37c828104b4496
account the FILTER clause of aggregate functions. Problem reported by
Manuel Rigger.
FossilOrigin-Name: 3cc2b5709e66ef605c3b85ed13ae6cc9c3090e864ebc18859db36284b8f715b6
is seen in the tree. Report the problem immediately, without continuing.
FossilOrigin-Name: 01ca865f31c0c817ede7f357401ef76cf311ae662397908464f53e1c147f5b6b
the file being inserted is a NULL. Bug discovered by the
Yongheng and Rui fuzzer.
FossilOrigin-Name: a80f84b511231204658304226de3e075a55afc2e3f39ac063716f7a57f585c06
by disallowing query flattening if the outer query is DISTINCT. Without this fix,
if an index scan is run on the table within the view on the right-hand side of the
LEFT JOIN, stale result registers might be accessed yielding incorrect results,
and/or an OP_IfNullRow opcode might be invoked on the un-opened table, resulting
in a NULL-pointer dereference. This problem was found by the Yongheng and Rui fuzzer.
FossilOrigin-Name: 862974312edf00e9d1068115d1a39b7235b7db68b6d86b81d38a12f025a4748e
