place if it encounters a NULL key. Fix for the bug described by
[forum:/forumpost/2482b32700384a0f|forum thread 2482b32700384a0f].
FossilOrigin-Name: 6eda9b1a7784cf6d58c8876551f67ab98e78a08e726a0579d4def5ba881985bb
1 and Vdbe.nOp-1. Had these assert()s been in place before, they would have
caused an assertion fault for the byte-code error reported by
[forum:/forumpost/2482b32700|forum post 2482b32700].
FossilOrigin-Name: 8f8a58feb7047d19522ca32efbe42fd9ddf49aaf9064f7373eb56a88982406a2
the IN operator right-hand side generator from the RIGHT JOIN no-match logic
does not generate unreachable byte code.
FossilOrigin-Name: cc458317bd77046c4328715ae9e3409f3f4cd422a01162cb33405ef3a142b0a3
logic for a subquery on the right-hand side of an IN operator. The code still
needs simplification.
FossilOrigin-Name: a193749730d6cfba617f2a64e7254c78f92bbf29b109c19055fc33f6cc643d4c
the use of that expression into a reference to the index. See
[forum:/info/7efabf4b03328e57|forum thread 7efabf4b03328e57] for details.
FossilOrigin-Name: a8da85c57e07721dc1c918d67433d6c99ce48421e369123cc3194d855e55f7e8
a right-hand side subquery is used as a constraint that needs to be processed
by the RIGHT JOIN non-matched logic.
FossilOrigin-Name: bb2798be3fb5737827eec505db2d4c8cb510d227d98fc26ce748bf2da7e8b382
able to reuse an IN operator that has an invariant subquery on its right-hand
side while coding the non-matched loop of a RIGHT JOIN.
dbsqlfuzz 19f1102a70cf966ab249de56d944fc20dbebcfcf
FossilOrigin-Name: 56dd3065469e49320b13af039471b3f0b85e6f7368cfd97b1cdc0cf8fa8e1956
1.0 and 1.1, then round it down to 1 rather than the using the default rounding
rule of changing it to 2. The reduces the estimation error for the
case where a column value is very nearly, but not quite unique.
FossilOrigin-Name: eb59c46a5aed69bc6fd096997bf24c082e533c1085439f6ec1fbe5ff78e8b374
check-in [664b461bb5063d980] and reported by
[forum:/forumpost/0d3200f4f3bcd3a3|forum post 0d3200f4f3bcd3a3].
FossilOrigin-Name: 134cfb18ff930e4bccc1a7412a02be353bf67c6d5080bc0673afaac81afa889c
sqlite3ExprIsTableConstraint(), not sqlite3ExprIsTableConstant(). This fixes
many problems, but still an error persists in join7.test.
FossilOrigin-Name: 10bf0e613809f71cc1a47ad40b517e2a66671212a6464e179c9d377e8b70d499
check-in [664b461bb5063d980] and reported by
[forum:/forumpost/0d3200f4f3bcd3a3|forum post 0d3200f4f3bcd3a3].
FossilOrigin-Name: 7ca3456c00998a429418ff29cf251b381586b330b88344c94a40c5df0b71da85
(see check-in [71272caff5874137]) in order to fix the first bug reported
by [forum:/forumpost/28821db852|forum post 28821db852].
FossilOrigin-Name: bd6811d8110d5f00596e2eff6d4b02af8b6d8557d41990e6f50518ead0fa01fb
escapes the subroutine, then abort the prepared statement with a descriptive
error and SQLITE_INTERNAL. This extra sanity check causes many tests to
fail.
FossilOrigin-Name: 2c5bb2bff26cc70d8cac78ddd12d5ac37ab1472f5f88afbd975950a18ac2804d
distinguishing between "subquery" and "join" and using consistent names
across EQP and bytecode.
FossilOrigin-Name: a2d3ee92420ec564e31eb0005367cf7ff3d00bfaed5a98ffdbe17c91c95d9d97
