clause. This brings SQLite into closer agreement with PostgreSQL and fixes
the concern raised by
[forum:/forumpost/1a7fea4651|forum post 1a7fea4651].
FossilOrigin-Name: 9322a7c21f1c22ba00e9b889223e89bc1591db6e561ce05091e905e98c1bf2b3
be reordered. [forum:/forumpost/6650cd40b5634f35|forum post 6650cd40b5634f35].
This is probably more strict that necessary to get correct behavior,
but for the first release that supports RIGHT/FULL JOIN it is perhaps better
to be correct than fast. A less strict constraint might be to prohibit
FROM-clause terms that originate on the left side of a RIGHT JOIN from
crossing from the right side to the left side of a LEFT JOIN. Revisit this
later.
FossilOrigin-Name: 238453ffab0ba1bdddb529be35da82d5e8fb312a9574003a5441f455e601a909
RIGHT or LEFT join anywhere in the query. Other RDBMSes prohibit this always,
but SQLite must allow ON clauses to reference tables to their right for legacy
compatibility, unless there is a RIGHT or LEFT join someplace in the query,
in which case there is no legacy to support.
FossilOrigin-Name: e615dbe02ca949252d1526ed5c48f8ce08159773ea2008ce666484379d0d9854
[forum:/forumpost/57bdf2217d|forum post 57bdf2217d]. This check-in
should complete the fix.
FossilOrigin-Name: fb0a23b6789da8e934562ce9ebd9d58ea13a10fd10dee5cbfc7ac8f394e1aeec
to turn it off. Update the invariant checking logic to be consistant with
dbsqlfuzz.
FossilOrigin-Name: 66ca729bbbf37cb7ff8eb12f51429e0c0833bd5d3f0ef20a1eaeeb10820713c2
sqlite3_bind_value() returns anything other than SQLITE_OK or SQLITE_RANGE.
FossilOrigin-Name: d31e1cd2ab44c7cce20b8990dff17719c286dd2fb46ba6d4f581a9553cf31891
blocking all failures. Then fix a few of the additional problems that are
revealed by that fix. More fixes are needed.
FossilOrigin-Name: 42b2e6676fed1508ea0ba17c292e83134825469735700da97817c45d45c54e66
use an unprotected sqlite3_value object as an argument to sqlite3_value_int64().
FossilOrigin-Name: d9f820151d74a690b5fa560597a5b3ace20165a112e1b58cb4a7c47b42745643
strength reduction if the query also contains a RIGHT JOIN. Fix for
the problem identified by
[forum/forumpost/b40696f50145d21c|forum post b40696f50145d21c].
FossilOrigin-Name: b1be2259e2e08ec22a88bc9a18b3ab4d83246ad4c635c05cdf80d3eff84df06a
in the presence of RIGHT JOINs also apply to the use of WHERE clause terms
to manufacture automatic indexes. This fixes a problem identified by
[forum:/forumpost/51e6959f61|forum post 51e6959f61].
FossilOrigin-Name: 342c501f532523347e6c339351e02043dd6ee9e11a291224b65ea72bd6c2ba40
as this can confuse RIGHT JOIN. Fix for the problem reported by
[forum:/forumpost/8e4c352937e82929|forum post 8e4c352937e82929].
FossilOrigin-Name: cab9b4cccd13bf0ab2bc38dc9a9c04ddd34e29c65ab6aef07b6bb3c31a43bece
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
