is in TH3. Fix for the problem described at
[forum:/info/ed29e196d5c4f3d5|forum post ed29e196d5c4f3d5].
FossilOrigin-Name: cd6254fcd32798f7be4e6d827597ddaa2e46ac6e2f0149cd3a3be0416fa18835
parse tree. This affects debugging builds only and is a no-op for production
builds.
FossilOrigin-Name: edbe24e7fc81ab6c26ab05f2231cb46d157d71a677ce8a2983e0c6e48122a2bd
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
has been initialized prior to continuing with the optimization. If the page
is not initialized, that indicates that the database is corrupt.
dbsqlfuzz 09ee46becd5e6d1b2a55c9f8ad767335a90aadb0.
FossilOrigin-Name: 11162446f12ae3af6e4a63bb5c374129b2505f6006f91d4028c7165f05fe9651
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
odd number of bytes on a database that is UTF16, the size of the resulting
string is reduced to a multiple of two.
FossilOrigin-Name: 5eb2c23635320b76f5e1aea4d94375b847fe4b38cdb4e287fba188753f4773b1
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
file (which can only occur if the file is corrupt) and fail with SQLITE_CORRUPT.
FossilOrigin-Name: cd7a44124558ea6a43c89b1cba4402d7bf6a6ccb83be0eeb7dd01b56933bca73
the designator from VdbeCoverageNeverTaken() to VdbeCoverage(). Test case
in TH3.
FossilOrigin-Name: 988a2a759f2b9da0e287e65306039b7a3e2b5aac3d31fe15cbb30d30ea6caf71
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
