from an UPDATE where the initial term is omitted. This can happen during a
UNION ALL query flattening while processing a virtual table update in which
the first term of the vector is repeated.
[forum:/forumpost/16ca0e9f32|Forum post 16ca0e9f32].
FossilOrigin-Name: 2547cfe38f8fb35109b3fc5bdfada387fe4b2b8a304156b704ab7f03f1f71198
to the number of columns in the vector. This is not strictly necessary. It
just simplifies the state description and make the code easier to reason about.
FossilOrigin-Name: 026f08d4cff19a95e0f38f2ef431cacd65c7c77ed92e30d7f2ded84651f47150
SQL. This prevents problems with statements like ALTER TABLE if the
function argument limit is set too low.
[forum:/forumpost/17735aa21f3ddab2|Forum post 17735aa21f3ddab2].
FossilOrigin-Name: 763fdec5b3151eeab001c50e78f654cd9b4b4c10e81e50a663046a70e64d5339
than once, as transformations that apply during the first pass might
cause problems for the second pass.
dbsqlfuzz 836b625cd8a41809ef80fc7ebaa6554357bcb463.
FossilOrigin-Name: f30fb19ff763a7cbe768ea49954704e14d6400f69bb4257c9c890e1564e14835
Also fix an assert() that was failing due to the recent TK_ERROR addition.
FossilOrigin-Name: dd56fbe0cfb0f7848190ce097b378321dd25ae509c7edf93682b091014824fc6
invalid subquery from causing problems downstream. If an error is found
while analyzing a subquery expression, change the expression to TK_ERROR
so inhibit further processing on that expression.
dbsqlfuzz cf624b8c0484c66e0f552bf6475e3e3f2c22b24e.
FossilOrigin-Name: 0be6b6c9f7c562e764792a4a5eb53ed11b230174b19361f7cd7778c743314bbd
speeds them up depending on the query. And (see
[forum:/forumpost/8692d94725|forum post 8692d94725]) it sometimes results in
an incorrect answer. We may come back and revisit this optimization later,
but for now it seems best just to disable it.
FossilOrigin-Name: 16252d73fa73569fd7506676f6ffbbcd43addfb105384fb74449d30ca720904a
to OOM. This in turn requires several new NEVER() and ALWAYS() macros for
unreachable branches.
FossilOrigin-Name: a61c0e6b78bd39f55464fafd257e68effded64995a66e8fa2d686e8c507ebe43
be false following an OOM.
dbsqlfuzz 9e8516bf1e786c84e520ae43141b75b7399f8618.
FossilOrigin-Name: 6af4e6d054efd8445e1010aabd584f36e70dfad0de13bd0e2f1761cad4d9a7d6
in the sqlite3ExprAnd() routine until the corresponding Parse object is
deleted. This avoids a dangling pointer in AggInfo if sqlite3ExprAnd()
is invoked by the push-down optimization. The dangling pointer appears
to be harmless in release builds, only showing up in debug builds.
Problem found by dbsqlfuzz.
FossilOrigin-Name: c36b43589abd9f62a709bdb47b8748e0c1e8743487a3d83d1eb35eb06b65d763
opcodes, allowing them to run faster. This required refactoring the
vector comparison logic, which in turn required changing OP_ElseNotEq into
OP_ElseEq.
FossilOrigin-Name: 380b46054b6a9b67e57357815e8e94057253fa3cce838ae76e5d5031c6bd26b2
scalar comparisons, rather than the SQLITE_STOREP2 parameter to the comparison
opcode.
FossilOrigin-Name: 93781b6f10a94fb273204b95156a8b90e07071f28c89e7966c659a0f44f60e98
schemas. Add the new SQLITE_MAX_DB constant for the maximum number of
schemas. [forum:/forumpost/a006d86f72|Forum post a006d86f72].
FossilOrigin-Name: 7b65fb9f7bd616f834633afd64b3448bf9ca2b6e4cc6d6c01e75d1d877c88a79
sqlite3ExprSkipCollateAndLikely() is never NULL in some of its use cases.
FossilOrigin-Name: 76d2eb86e109fc3cbdba2e8175c22ed7660b59bb9315f6c55c565587f33ad43b
Fix to check-in [ac31edd3eeafcef4] which was itself a fix for ticket
[45f4bf4eb4ffd788].
FossilOrigin-Name: 871f2ddcfbb9196dbd851a350e3471ee6d242d86bbd755201f7e2406fce3ac55
that created them has exited. So AggInfo cannot be a stack variable. And it
must not be freed until the Parse object is destroyed.
FossilOrigin-Name: 3c840b4df306e2db1da08673e9ede973b4cb6d2b3f9eeeab5835e39452ee3056
dan