| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
| |
a RIGHT JOIN.
FossilOrigin-Name: fdd782a7bb217e2aceda97a588c0d7874ee19885abfcf0658472d6c3387da6ee
|
|
|
|
|
| |
[3869fd9a2b9483cbf] but which turned out to be necessary after all.
FossilOrigin-Name: aba52a90eef2a5d06e7c499fe84b2efcde7f01e67129058f8223a6a0272aacb9
|
|
|
|
|
|
| |
the right moment - not too early and not too late. Fix for the problem
reported by [forum:/forumpost/3902c7b833|forum post 3902c7b833].
FossilOrigin-Name: 3869fd9a2b9483cbbf83d8f369c1744abc42f12e63abba402be35dd7e136161c
|
|
|
|
|
|
| |
join that is an operand to a RIGHT JOIN. Fix for issue identify by
[forum:/forumpost/c06b10ad7e|forum post c06b10ad7e].
FossilOrigin-Name: 9d17233c7d98bf25c1a518d067e778708b3db6d6302edd8d7e376ba0ba4f1c30
|
|
|
|
|
| |
right-hand side might be a non-matched row.
FossilOrigin-Name: 0f96810b840dd6f209562635b21f55a7ed6210c01336fcfeb3b79e08a615a28d
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
EP_OuterON and EP_InnerJoin becomes EP_InnerON.
FossilOrigin-Name: 1ffea07ff98b894729c698b681cc7433df3bbfccd8a0529a706908602a636937
|
|
|
| |
FossilOrigin-Name: c7e3a13a3288c577209be99c630fbe924e19880e8af1aa8a83b517acaa8b43d7
|
|
|
|
|
| |
are coded.
FossilOrigin-Name: b57033d2af2196e2f7e5305f3504fc20da5cadeb66026d38b999fe909cab8ac5
|
|
|
|
|
|
| |
place if it encounters a NULL key. Fix for the bug described by
[forum:/forumpost/2482b32700384a0f|forum thread 2482b32700384a0f].
FossilOrigin-Name: 6eda9b1a7784cf6d58c8876551f67ab98e78a08e726a0579d4def5ba881985bb
|
|
|
| |
FossilOrigin-Name: 053cf45ecaa7eac8cc64c7b2672807f736a45575a84b426263b2e1feb060b401
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
running the right-join post-processing loop.
FossilOrigin-Name: fd328e52aee1dace12b1c2f44b6f7e9d15d8f77c8e9d9e3d85840a129a4b1808
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
subroutine.
FossilOrigin-Name: 1549dcd2353903b70abadd428eeef971ab940df04fb05a6b83b04ee30932db6d
|
|
|
|
|
| |
the RIGHT JOIN body subroutine.
FossilOrigin-Name: 9b9038bcd0ab5c4f01661456635526cef764f854ff24018a5e6e43825d07eb59
|
|
|
|
|
|
| |
verify beginning of the loop - to make the start of the loop clearer to
human bytecode readers.
FossilOrigin-Name: 7ed2a271e6fcbb5e69a7f3a88d3f45fe6318819c0cc6a0dcc06c3dae5aa1503f
|
|
|
| |
FossilOrigin-Name: 218c7167e562f5c327124f02a92de85079315320a221fb0508310d927596b14c
|
|
|
|
|
|
| |
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
|
|
|
| |
FossilOrigin-Name: d91faeffea5cf0585fb71e5311fdcc6b8be85c7e9c732050b4448e617c970101
|
|\
| |
| | |
FossilOrigin-Name: 29927926eb32acd963e2c496ad67d55177615ec4150fd218afaf2f9a730cabec
|
| |
| |
| |
| |
| |
| | |
"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
|
| |
| |
| | |
FossilOrigin-Name: 549f5a7ee639de80f049445002f58e93c805f9a3d3db1987ec9d139ccef4805e
|
| |
| |
| |
| |
| | |
Much more remains to do.
FossilOrigin-Name: 55b4543122646997d928598343bc467c993f971e86e9037c85430cc948750576
|
|\|
| |
| | |
FossilOrigin-Name: b1b3845aa38f469a27f07c8f6e8a98334f7967b19661ee4cf155d6997afd9d4c
|
| |
| |
| |
| |
| | |
deleted when the corresponding WhereInfo object is destroyed.
FossilOrigin-Name: f237e1d8cc41b937f34288daebfacf5f7b0990a807a805e0cb6b45bc730192d6
|
|/
|
|
|
|
| |
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
|
|
|
|
|
| |
processing a multi-index OR.
FossilOrigin-Name: d71fb6fdc32d2fce73059b6ab86d7d7bbc812c637469755dd45b6794aadc3a80
|
|
|
|
|
|
|
|
|
|
|
|
| |
[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
|
|
|
| |
FossilOrigin-Name: 54f49f65ac943263a1622b1efe519c8a61f30f23694fd4fec89ad2bf0e17b473
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
all at once, rather than one element at a time.
FossilOrigin-Name: eb84b80e1f6d8c32bf0c9e1731f0233de0160a13f714f766779ae01fdf504e7b
|
|
|
|
|
| |
SQLITE_INDEX_CONSTRAINT_OFFSET constraint.
FossilOrigin-Name: 38c5151eb8cc789ad082a1b40d16b2ddb55454219bd685b6e420995af6a15f55
|
|
|
|
|
| |
clauses.
FossilOrigin-Name: 74fa5757ee0a8499bcd6546dac1a3ecc6048ba9cff9e3e574e28e6e82e894a3d
|
|
|
|
|
| |
cause Parse.nErr to be non-zero.
FossilOrigin-Name: 1f7fa46126ea33ed30e93186aff3df51068aeb4be6f79a102bfe8c4e44941d71
|
|
|
|
|
|
|
|
| |
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
|
|
|
| |
FossilOrigin-Name: ce42039f5647b1f276acf5d9911528ecb47df1544a587def72c8cd6b2f664289
|