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: 274e244c85935084b2f0f85176283f018bf9b74e7703f985bd5a2f6f8bdcff5d
turns out we should never allow a zero key into the pcache interface according
to the design specs, even if that page is immediately released without ever
being used.
FossilOrigin-Name: ec96293ead83603ebe5d7f250d6fdc11f22172f05a9513f175331437c3eaa4c8
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: 44d77a7f807f5dc3e94e6cd88a27bea79257f0f2ccf332891bdaa4668d0bb987
value for all outer Parse objects.
dbsqlfuzz d33f60aaa67733aa700cd69dacf8e0e23a327a29
FossilOrigin-Name: 9a494d25944f4f640026e7a7ae2948e555d7af31487c55ed2ec2818a0789b887
it with an assert() to show that the initialization has already occurred, for
a small performance increase and size reduction.
FossilOrigin-Name: 27be9e963459ca0b20c339264125e175550debf50fdbec7d78412768a6326b42
needed, in case they are not needed. This gives a small performance increase.
FossilOrigin-Name: 6f28a9652a3f1e5354afb76314db8f33f92f5e888e336d025f34881c0a8d64ae
into a single spot for small size reduction and performance increase.
FossilOrigin-Name: a1c090e08139f99d30aa89db0756dc59fe8990ce15b3db4d4b726cc6acdab46f
cycles by omitting the loop termination condition and exiting when the
OP_Init (always the first opcode in any VDBE program) is encountered.
FossilOrigin-Name: bb179140c8abfd9d05d62380daba027bdeabbbafc720b7e36b99a36af806017e
in an aggregate query as long as there is no GROUP BY clause. (The GROUP BY
clause will interfere with the operation of the TK_IF_NULL_ROW expression
nodes.)
FossilOrigin-Name: 2cf373b10c9bc4cbc5fe63d0a6948011df7bbc2f40dc025c9349f875da782b88
is in TH3. Fix for the problem described at
[forum:/info/ed29e196d5c4f3d5|forum post ed29e196d5c4f3d5].
FossilOrigin-Name: cd6254fcd32798f7be4e6d827597ddaa2e46ac6e2f0149cd3a3be0416fa18835
the outer query holds a GROUP BY, not if the outer query is an aggregate.
FossilOrigin-Name: 641dfb9182a6cbadb3c452f5420f896791b7844b794f693443bcd38dca14da35
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
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