"expr IN ()" to "false", take care not to delete aggregate functions
in the "expr" as doing so can change the meaning of the query.
See [forum:/forumpost/f4878de3e7dd4764|forum thread f4878de3e7].
FossilOrigin-Name: 77397bd67d918db57d5ac545d6d963194806fdabcdaa8f822b6b09e4cfe8b715
other operand is NULL into a subroutine, so that it can be more easily reused
by other parts of the code generator.
FossilOrigin-Name: 3c6c71bcea16443b82234414137dfa1b59e2ee8fe5097906c738fc1228fec4e6
a subquery and the other operand evaluates to NULL, the subquery operand
is not even computed. This fixes 5 of the 12 slow queries described
in [forum:/forumpost/52651713ac|forum post 52651713ac].
FossilOrigin-Name: f147bc04776ac0056412f69dfc518016c0d5b4e9d964664e3d88f595fb29dbe0
NATURAL JOINs to the left of RIGHT JOINs where source tables are views
or subqueries. Initial problem report in
[forum:/forumpost/829306db47|forum post 829306db47].
FossilOrigin-Name: f184d1d236e47962658a4639d9533f67a525b74cfe0f06c93e9b85fdcd02a15f
that can cause invalid data to be used for a column if that column has a
CHECK constraint that includes the NOT NULL or IS NULL operator.
Problem discovered by the
[https://issues.chromium.org/issues/415397143|Chromium fuzzer]. Never
seen in the wild, as far as anybody knows.
FossilOrigin-Name: 2adaee9aa90f280a406007695fbc4a314806584c93d6b62b46c031492b31ec27
See [forum:/forumpost/792a09cb3df9e69f|forum post 792a09cb3d] for
a description of the problem. Also improve comments related
to [baa83b460c677c21] which was origin of the problem.
FossilOrigin-Name: cdef486e212fe4b26605065d9cff08f608cb80df48ee64e4be63637769bdfacc
pacify -fsanitize=strict-bounds. This check-in fixes the core. There is
more yet to do in FTS3, RTREE, and in FTS5.
FossilOrigin-Name: 6fd6b32d06bd6a705e5140cd613af823b8183a6f6a9ceeeedfcf5e8b50821d68
to use more than SQLITE_LIMIT_COLUMN columns and raise an error.
Also include some unrelated compiler warning fixes.
FossilOrigin-Name: d7729dbbf231d57cbcaaa5004d0a9c4957f112dd6520052995b232aa521c0ca3
happen during memory allocation. No problems fixed; this change is just
to make future maintenance easier.
FossilOrigin-Name: 215650a5a1d55bdbca9c92524804a1a54456a17f42a17e53747b21a6507506f5
than using a custom loop. Performance improvement, size reduction, and
complexity decrease.
FossilOrigin-Name: 351dbbc2bf0b23efdc625ddaa5dc2239cf2990addf071a04bd41612b341de8c8
capability to increase it further up to 32767 using a compile-time option.
FossilOrigin-Name: e8d7d68ba0bb0bc2f948db5d9966990a5d23597fc3658b7cd0bc99d53c7353a9
SQLITE_ENABLE_UNKNOWN_SQL_FUNCTIONS. Problem introduced by [eb5ac9e5b9a4f9c8].
FossilOrigin-Name: 3ec2df5a6c731b59b0ab132ee59c74d107f9c4bd32cf47d9776887858b9c0dea
in a separately allocated Subquery object. This reduces the memory requirements
for SrcItem and makes the code run faster. It also provides an expansion path
for subquery processing that does not burden simple queries. The current
checking mostly works, but there are still issues that need to be tracked
down and fixed.
FossilOrigin-Name: 8ff5dda8448d7e1a533d7f27db2573ce68fa9956b9d9847ced45e83c1f06bab0
prior SubrtnSig objects when generating code for IN operators with subqueries
as their right operand.
FossilOrigin-Name: d8cedbe055b40a0ea4e5d47845b535162e9fcb0d0f88c03211797ab64d2d56fb
"SELECT ALL". The ALL keyword is almost never used in actual practice (most
developers don't even know it can be used) so this should not interfere with
the optimization, but it does give us a convenient way to turn it off for
testing purposes.
FossilOrigin-Name: a81299be2ce203dcc28e7d0ba24791cbfba80e1ee3e1564469a226cac8adb17d
operators that have been replicated due to the predicate push-down optimization.
FossilOrigin-Name: 2accf32b6e45a396503c29eecc14a103bcc7b4c313cde921b26b489704060177
prevent an infinite loop, but which can now never be reached due to recent
changes.
FossilOrigin-Name: da0b794852f8ccba5bd30395892044ec71b148075608406867785395e1f50b31
