the SQL that is run to verify that a found query-invariant discrepency is
valid. Changes to testing logic only.
FossilOrigin-Name: 8f45ad27403e971d88ec62e674c03f82eb19df0b43aa58d20b3400cdb6611d90
in the WHERE clause, since if the subquery is hidden behind a short-circuit
operator, the subquery might not be evaluated until after one or more rows
have been updated. Fix for the problem reported by
[forum:/forumpost/0007d1fdb1|forum post 0007d1fdb1]. This is the same
problem that was fixed by [73f0036f045bf371] only for UPDATE instead of
DELETE.
FossilOrigin-Name: 2c56b984a0bd3be5ec326a2109ea7b8f1d4ef63c8fc325caac9663cf2479eaff
found could sometimes be reached. I will find a way to test that branch
later.
FossilOrigin-Name: 1dffeffe150fff6777cf26bc960326ca4e4190d25d05bb066b082d1e1c8eb374
a subquery. Fix for the problem reported by
[forum:/forumpost/e61252062c9d286d|forum post e61252062c9d286d]. This fix
is more restrictive than necessary. It could be relaxed if the subquery does
not involve the table that is the subject of the DELETE.
FossilOrigin-Name: 73f0036f045bf37193b6e87ae45b578c5831614c530488257c69666178da3aa5
[forum:/forumpost/2e427099d5|forum post 2e427099d5] and
[forum:/forumpost/d47a0e8e3a|forum post d47a0e8e3a].
FossilOrigin-Name: c028fb669a5ae34dbaf50fffab1ae49bc568b994435cf02e145d24da3cfb48d7
queries, which is here fixed. Problem reported by
[forum:/forumpost/b405033490fa56d9|forum post b405033490fa56d9].
FossilOrigin-Name: dc9f025dc43cb8008e7d8d644175d8b2d084e602a1513803c40c513d1e99fea4
enhancement at [bd8fa10e59f58886]. Reported by
[forum:/forumpost/f5a2b1db87|forum post f5a2b1db87].
FossilOrigin-Name: 84417bbd144b2197c9930a520feb94b59053957c190be79f8deaaaebca68ecf1
Expr.affExpr field of a generated column expression if the expression is a
RAISE() function, as affExpr has a different meaning for RAISE.
[forum:/forumpost/b312e075b5|Forum post b312e075b5].
FossilOrigin-Name: 1096b5a7cc8104db01f8820ace47020baad2f12e6711e3a7b4514ed1becc7b66
historical datatype ("INT", not "NUM") for a table created as follows:
"<tt>CREATE TABLE t1 AS SELECT CAST(123 AS INT) AS value;</tt>".
FossilOrigin-Name: a0e54fe2058a4ac1e794b2491e424c60dfa42c6781b1cfd83c5db65c28c11c71
SQLITE_DBCONFIG_REVERSE_SCANORDER opcode to sqlite3_db_config() to make more
accurate judgements about when a query is ambiguous, and hence when query
invariant testing is approprate.
FossilOrigin-Name: be9ab292cd14889b1c9648b47138260b33fe5be282ff2d90653b1387885a7d02
requested by ticket [99378177930f87bd] - that can cause an incorrect answer
if an aggregate subquery has a GROUP BY clause, and that GROUP BY contains a
term that is not in the result set, and the outer query makes use of expression
indexes. Problem reported by
[forum:/forumpost/a68313d054|forum post a68313d054].
FossilOrigin-Name: e06973876993926fd56181281d04b8dd504c689abf883fa21a5721cc1d478ea8
bytes at the end of an index record, which might cause OP_IdxRowid to
malfunction. dbsqlfuzz c1aa3986534d5feab8d21f28b3c1712df2ef358ba. Test case
in TH3.
FossilOrigin-Name: f418bdd627e84e7d494f730d7124d8f4846ebcde031f5b2498685c9aceebb3c8
has the wrong affinity. dbsqlfuzz 65f5eb57f8859344d5f1f33e08c77ee12960ed83
FossilOrigin-Name: e95439119ac200cb47d0e277622f41ee7986b364487cd252b485ce5fa030d70f
(check-in [41c27bc0ff1d3135]), ensure that the OP_IfNullRow opcode does not
NULL-out a subquery result that was computed within OP_Once. This fixes
the problem problem reported by
[forum:/forumpost/402f05296d|forum post 402f05296d].
FossilOrigin-Name: 8fe13f7a5e5eb798189acb25a608df7a94c2f5cc83463331a048b779c7890c82
the optimization of check-in [41c27bc0ff1d3135], always insert the
TK_IF_NULL_ROW expression nodes, even for TK_COLUMN expressions, as
the TK_COLUMN might be a column from an outer query and hence still need
to be NULLed out. This fixes the problem described by
[forum:/forumpost/26387ea7ef|forum post 26387ea7ef].
FossilOrigin-Name: 198b3e33dcfd74c7ba6abcf789ee81dfed464a50ebf15c8edeff349d36789fca
