the join8 test module, with tests that deliberately fail in order to remind
us to fix the issues.
FossilOrigin-Name: 2c4ee723f4d0591d09776adfb82246bfa89153ab390b8b3f1878d1cdc43d68c8
remove the "or unsupported" clause, because we now support all valid join
types.
FossilOrigin-Name: ab0a0562dd3594cf50ee56f6b3a5847fa5dcadf69146d560e3e7a95651b8f405
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
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
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
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
IS NOT NULL constraints from the WHERE clause when operating on a LEFT JOIN.
[forum:/forumpost/031e262a89b6a9d2|Forum thread 031e262a89b6a9d2].
FossilOrigin-Name: 1a6328f2a5b4973094e5f85787145d652119822c86ec01a61f3f985c9d2903f2
(check-in [0057bbb508e7662b] about 16 hours ago), be sure
to clear the BTCF_ValidOvfl flag, since the overflow cache is invalidated
by the search on the last page. OSSFuzz issue 45329.
FossilOrigin-Name: 0021bebc162e001b788786703ce634e7b8fcd3976f7047a5956e82140791e765
to avoid violating invariants associated with Expr nodes. See
[forum:/forumpost/2024e94071ef1531|forum thread 2024e94071ef1531] for more
information.
FossilOrigin-Name: 5e0ed49b3d739d292f5df3e498449ae8f4357cbb83394181fb34f98ed8372707
[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
to cover the entire database. Fix for the problem identified by
[forum:/forumpost/3b9e894312|forum post 3b9e894312].
FossilOrigin-Name: 12c012162ce110a7a7fbbe853f422e23cb4ae10b45237727328c8f3315b70842
there is a RETURNING clause, since that optimization is not able to deal
with RETURNING. See [forum:/forumpost/595e132f71|forum thread 595e132f71]
for details.
FossilOrigin-Name: 1d3760a517b8bd2a6be82d2d5788945f49397cdc539fe28fd23e2c0c62a1dbe2
EXPLAIN and EXPLAIN QUERY PLAN do not affect the return value. Add test
cases to verify this. Add new test cases and requirements marks for
complete requirements test coverage on this interface.
FossilOrigin-Name: a6fbb7ba0583b3981e2d8b809006b902b3e97e516dbd3ab7d905c5ea73df2272
