join that is an operand to a RIGHT JOIN. Fix for issue identify by
[forum:/forumpost/c06b10ad7e|forum post c06b10ad7e].
FossilOrigin-Name: 9d17233c7d98bf25c1a518d067e778708b3db6d6302edd8d7e376ba0ba4f1c30
reuse the same ephemeral cursor of a list subquery when that subquery is
reused, as it does not work in cases where the list subquery is used both
for lookups and for scans.
FossilOrigin-Name: 12ee29d632ae4b585ef6bc07d3289d00c121268945dffd5673b251d95874e3f8
ON-clause processing for the RIGHT JOIN has done its own row elimination.
This fixes and incorrect output from some RIGHT JOINs that was identified
by [forum:/forumpost/41cc3851d864c5e6|forum post 41cc3851d864c5e6].
FossilOrigin-Name: 238d9c247cf69cc77fdb1af9d42ebe258610a533ac4204e2ddf8af17f24d18c4
place if it encounters a NULL key. Fix for the bug described by
[forum:/forumpost/2482b32700384a0f|forum thread 2482b32700384a0f].
FossilOrigin-Name: 6eda9b1a7784cf6d58c8876551f67ab98e78a08e726a0579d4def5ba881985bb
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
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
to running the right-join loop. This fixes a problem introduced by the
previous check-in.
FossilOrigin-Name: aab7665ce6c004df701a72aef1a5135f2c78f16c6ff728a00076afb66ba9d3a0
introduces some new faults in the tests, probably due to something
unrelated.
FossilOrigin-Name: 95b242d4c2fed7c713299565ac1010f8a7534a5695589e87d5a0204c7bf5f3dc
verify beginning of the loop - to make the start of the loop clearer to
human bytecode readers.
FossilOrigin-Name: 7ed2a271e6fcbb5e69a7f3a88d3f45fe6318819c0cc6a0dcc06c3dae5aa1503f
reduces the register pressure on that routine and helps it to run faster
in the common case where there is no RIGHT JOIN.
FossilOrigin-Name: beeecf1604d4fb11e45058f48cb2289c6542e0bc218d63a245198113d8d5476b
"RightJoin" in the former name do not lead readers to believe that this has
something to do with RIGHT JOINs in particular.
FossilOrigin-Name: e8c00442d2daedec079748d13147bf73b0ec3c3cf432bce2cdccb706bdff2853
the code to compute the unmatched rows for the RIGHT JOIN has not yet been
added, so the result of a RIGHT JOIN is currently the same as an INNER JOIN.
FossilOrigin-Name: 415abd6731b8e8a605adabfa6066c8a852a8531c300df41325d5f7e75cae5a70
implements the loop body for the multi-index OR optimization is indented.
FossilOrigin-Name: c2965fea9df7076b235d3eadaf84f0a36242476d0329030b0e57557b66e2540c
so that they work even if the "omit" field in the sqlite3_index_info object
is off. This has apparently never worked correctly before. Presumably, nobody
has ever before written a virtual table that can use vector IN operator
constraints and that relies on bytecode to double-check the constraints.
Test cases in TH3. Problem discovered by
dbsqlfuzz cab8e26194a40147627094f3c6849c0a7b1e0310.
FossilOrigin-Name: 21b656572d066b640ff5774205a4f0db13e1b08a35d0fd484da9130e759b0c26
[forum:/forumpost/0cd8e058bf|forum post 0cd8e058bf]:
When evaluating an multi-index OR, do not push down auxiliary WHERE clause
terms that involve subqueries into the OR-subqueries. Otherwise, the
covering-index optimizer might convert table-references into index-references
for the particular OR index that is active for the branch in which the
subquery subroutine is coded, and those index-references
will not work if the subquery subroutine is invoked from a different OR branch
that uses a different index.
FossilOrigin-Name: 61a1c6dbd089979cbeb8b0c0c5ee1ab1abcb466be1d21a3a851be73c27e67a6c
Make sure the query planner does not try to to both.
[forum:/info/50a1bbe08ce4c29c|Forum post 50a1bbe08ce4c29c].
FossilOrigin-Name: ad3ffa1a75a5a032ebb64d8e014ee0a85c5e44b732e4b11bd67f31a59e729b94
Expr.w.iOfst field. This is done with the idea of providing offset
results for sqlite3_error_offset() for a more kinds of errors, though that
part is not yet implemented.
FossilOrigin-Name: 32a3a53b62ab09ac2212905e7f42fe6f1b09d891e015203e5caf4cb16262f18e
the main query into the various OR-term subqueries, do not push down slices
of a vector comparison, since the right-hand operand of the comparison might
have only been initialized in a different OR branch that was not taken.
dbsqlfuzz 80a9fade844b4fb43564efc972bcb2c68270f5d1.
FossilOrigin-Name: 9f67ad00cd38b7c5ec6d14b379e1a611777bbdf6901d843a80712ba7d94d6d33
check for NULL values and abort until after all key values have been
computed, in case one of the later key values involves some initialization
that is needed by a LEFT JOIN. Fix for the problem identified by
[forum:/forumpost/ab95010d410a0a55|Forum post ab95010d410a0a55].
FossilOrigin-Name: 4db5217a28ce767fa14ddfe51cf3ca25eceb72079d46a2fc00f7d6b8ae9abe0b
the machinery to deal with the IN operator is not available.
dbsqlfuzz 5b51c247518278f79a45cea978702e86e86cd4f9.
FossilOrigin-Name: 799db7cb2e0d73031182d26a0e5919368f9f9823df81cb2863bfe79eca344f5c
sqlite3ConstructBloomFilter(). OSSFuzz is reporting a crash with a garbled
stack that we cannot reproduce. Perhaps the original "constructBloomFilter()"
name is colliding with some internal name used by OSSFuzz. We'll see if this
rename clears the problem.
FossilOrigin-Name: 403e7312dd9a3fe493a21aceb82e387d6f152622d66c1b403c881597713e8cc3
drh