FROM clause terms that existed prior to version 3.39.0 for queries that
contain no RIGHT or FULL JOINs.
FossilOrigin-Name: 92d60b64ebfc2d1f0a9cabaa88e7bf0d11737ed01a77b627af10dd1b96a5321c
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: 0620e419a927a3da6ebe921aaa3471686f0fdc2e485f4c2d5c88f32092228724
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
larrybr