verify beginning of the loop - to make the start of the loop clearer to
human bytecode readers.
FossilOrigin-Name: 7ed2a271e6fcbb5e69a7f3a88d3f45fe6318819c0cc6a0dcc06c3dae5aa1503f
remove the "or unsupported" clause, because we now support all valid join
types.
FossilOrigin-Name: ab0a0562dd3594cf50ee56f6b3a5847fa5dcadf69146d560e3e7a95651b8f405
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
unmatched row pass. This is a cheap opcode, and it adds an extra layer of
defense against incorrect results.
FossilOrigin-Name: a3d14e61ca22167296fee125a3e9aa63413408955e03bb3f9d85fa9f22df1b79
that land on the left operand of a RIGHT JOIN, just as it already does for
the right operand of a LEFT JOIN.
FossilOrigin-Name: 8e02cdf5b1128f5e5b82d93903063415ec312694e5ccdd19e99fa35433f1b68a
constraints on outer joins, and (3) ON/USING clause constraints on inner
joins. Formerly, there was no distinctionb between 1 and 3, but RIGHT JOIN
needs to know the difference. Make RIGHT JOIN aware of this difference and
add test cases.
FossilOrigin-Name: 0f6f61c3664cc87209c2a6f9b6df3a750d1510723fcde209c33db8feaf48bcf3
"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
automatic indexes must be WHERE_IDX_ONLY, but the RIGHT JOIN post-processing
does not know how to work with an index-only scan.
FossilOrigin-Name: beb4401dc09fb68e85ddcf3f99598527691535d0eb7693168f440e5a5a076e3f
that are to the left of a RIGHT JOIN, to avoid other complications.
FossilOrigin-Name: cf00ebfc4b77f45ec466b0d57d7c22c7f48acab19e4e55b168eb4b53f390d887
out to be an effort to convert RIGHT JOIN to LEFT JOIN if the join was on
the first pair of relations, but that messes up the "*" expansion and so won't
work.
FossilOrigin-Name: a48902c71ed30c83de7dbd26d1c7956136c35dc53b1076bc8b1ebcba568a3fd3
make sure all its columns are flushed to NULL when it finishes so that
they appear to be NULL during the RIGHT JOIN post-processing.
FossilOrigin-Name: f84b2beca719758979d7a5a63c3d16d5121a7518b3fbe5039af474a83dd569c2
Compiles, and the code looks semi-reasonable, but still does not run.
Incremental check-in.
FossilOrigin-Name: 2db5a498e74241dd19ef51c601f1a2b3b687faed3e1be2d1e3ada737406ac8e9
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
from about a month ago such that it still takes a transaction on all attached
databases, but it only starts a read transaction for read-only operations,
rather than starting a write transaction for everything.
FossilOrigin-Name: 8efd61e8518594e3e9c84681fc35796a78fe8885a97ad4dd19f1573ee8065b18
of the error messages changes slightly, but besides that everything works
the same.
FossilOrigin-Name: 48f2e5a1fbaa8ceb32e08066766be74233b0c67ab430bbf7adfdff42cdb7b8ec
implements the loop body for the multi-index OR optimization is indented.
FossilOrigin-Name: c2965fea9df7076b235d3eadaf84f0a36242476d0329030b0e57557b66e2540c
OP_ReleaseReg opcodes. OP_ReleaseReg opcodes are usually only generated for
SQLITE_DEBUG builds and are used to verify that registers are descoped
propertly. But they can get in the way of code understanding when studying
bytecode dumps. So this new optimization setting is provided to
temporarily turn OP_ReleaseReg opcodes off.
FossilOrigin-Name: fa5276725f246cef9d58b27c1e617ee3f873f7a9b88284a4e8fc453ebda338bc
[forum:/forumpost/b6edc69548|forum post b6edc69548]. This has no affect
on SQLite itself.
FossilOrigin-Name: 201569e09b000919ccb463bd581fb2ecd5320e7f584fdb1bc2aaba111061d5c3
