FROM clause terms that existed prior to version 3.39.0 for queries that
contain no RIGHT or FULL JOINs.
FossilOrigin-Name: 9141e873c575b049ce7aeaf313d05966f1966087caf33a6c80d2416a28571a21
is able to cope with row-value comparisons against the primary key index
of a WITHOUT ROWID table.
[forum:/forumpost/3607259d3c|Forum post 3607259d3c].
FossilOrigin-Name: 2a6f761864a462de5c2d5bc666b82fb0b7e124a03443cd1482620dde344b34bb
a RIGHT JOIN in any arm and the subquery is not the first element of the
outer query. Otherwise, prior elements of the outer query will not have
the JT_LTORJ flag set. Fix for the problem reported in
[forum:/forumpost/174afeae5734d42d|forum post 174afeae5734d42d].
FossilOrigin-Name: cf9ed7f2e1a7be230a8ff689a759289a6bf59c1c84169f2ed510f74c02e0c2e0
a nested parse. Fix for the problem identified by
[forum/forumpost/d5a82ba9eedee30c | forum post d5a82ba9eedee30c].
Also, remove unnecessary clearing of the Parse.zErrMsg field
following a nested parse.
FossilOrigin-Name: eaef7b71900ef7701c11f07ec8b0ca3fec7e055ce8fd9c769f36669b482de134
works even if the prefix contains characters that require a 3-byte UTF8
encoding. This should fix the problem reported by
[forum:/forumpost/96692f8ba5|forum post 96692f8ba5].
FossilOrigin-Name: 7a32ccccef7712a40aba86c2204457f6772403befabe0aab19407399df46f096
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
drh