Proposed fix for the problem reported by
[forum:/forumpost/3d9caa45cbe38c78|forum post 3d9caa45cbe38c78].
Additional works is needed as not all cases are covered.
FossilOrigin-Name: 08af1fe27ebd0edf6e0f1ac477deea033e7f7c813f1016b75196836daf02d2e4
an inner-join and outer-join ON-clause constraint (or equivalent) on the same
term of the FROM clause.
FossilOrigin-Name: f6c4fb48b65c2e8659aa0a1119c330e8bad5e42b2db2030850bfc9c04afef5c8
since the index is partial, some rows will be omitted from the scan, and
those rows will subsequently be picked up by the no-match logic in the
right-join post-processing loop.
[forum:/forumpost/c4676c4956|forum post c4676c4956].
FossilOrigin-Name: 615c0026119f7870c3b6ef9dcb57ce4ecf5acedea3e2b5cfc25aa450eb8f17a0
the right operand of a RIGHT JOIN, since this can cause problem if the
constraint implies a not-NULL value for one of the columns for the left
operand of the same join. See
[forum:/forumpost/206d99a16dd9212f|forum post 206d99a16dd9212f].
FossilOrigin-Name: 4a31b7942a15c9c4363477365784d6d4ac5b1bbe8ff8aeaf2dd3d6532bf8bc96
used when processing a RIGHT JOIN. Fix for the problem described by
[forum:/forumpost/087de2d9ec87305b|forum post 087de2d9ec87305b].
FossilOrigin-Name: 5a9465dcc0c23fc2c66cd4898bcdfd5086fe4c71ec19a95db7221fdf7c0bbbbd
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
FROM clause terms that are even further to the right. Fix for the issue
identified by [forum:/forumpost/5cfe08eed6|forum post 5cfe08eed6].
FossilOrigin-Name: 4be0c60e38edc5d5bfd72bb35a3c91c55240b4e6313a40614beb60f1ab9d9f4c
of the join, just convert the ON clause to an ordinary WHERE clause term,
in order to be compatible with older versions of SQLite. See
[forum:/forumpost/687b0bf563a1d4f1|forum thread 687b0bf563a1d4f1] for details.
FossilOrigin-Name: 2b6ebba26d936ae7b9acf7d4bd15e82cbfabda22e1044b3dd838c7b07095100e
for LEFT JOIN versus RIGHT JOIN that protect legacy behavior.
[forum:/forumpost/e90a8e6e6fa652ac|Forum thread e90a8e6e6fa652ac].
FossilOrigin-Name: 2c586060a016f5481bad29bfb8f4ac4e1204075afdd0fa1851fbbcf2abda4893
the index might not be positioned on the correct row when running the
the right-join no-match loop.
dbsqlfuzz 39ee60004ff027a9e2846cf76e02cd5ac0953739
FossilOrigin-Name: 2277f9ba7087dd993ac0f4007c523aa9cf74dba187f53af03d8c164886726fee
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
answer. See [forum:/forumpost/41cc3851d8|forum post 41cc3851d8] for the bug
report.
FossilOrigin-Name: 02b24863e6dc617c9260f79292a96b7c861d088268e77fd17204570515eb792c
equivalent to IS and IS NOT, respectively, for compatability with PostgreSQL
and hence standard SQL.
FossilOrigin-Name: db27611e172102483eaede3981d473e3d5bf93d98bc68f480398b1573876349d
chekc-in [f237e1d8cc41b937]. The bug was detected by dbsqlfuzz
test case 4c5e3e89bc251d28378be88233f531b84ec66901.
FossilOrigin-Name: 764b71267e0b31ff7eaf2a0def7526a1a02dce4d5b456dea060d97ed342efdd1
