omit-noop-join optimization. Fix for the issue reported by
[forum/forumpost/49f2c7f690|forum post 49f2c7f690].
FossilOrigin-Name: 3e9c9bbdb59b9d500ff218db538c047c83da7ac18ebb95c3ee7629ab15e0b43a
ON clause of a join. Fix for the problem identified by
[forum:/forumpost/96cd4a7e9e|forum post 96cd4a7e9e].
FossilOrigin-Name: d095da0e7a24e3bcab6495d964f76a86d7a5910d2d6edddc6e8092bfa6084fe6
is on the left side of a RIGHT JOIN do not need to be in the ON clause. Add
new test cases and tags to associated test cases with the code.
FossilOrigin-Name: 18ee689de3d1ae43b05ca52e0b62c49442ebf68a88814a7c679e8856250a4b0d
remove the "or unsupported" clause, because we now support all valid join
types.
FossilOrigin-Name: ab0a0562dd3594cf50ee56f6b3a5847fa5dcadf69146d560e3e7a95651b8f405
the code to compute the unmatched rows for the RIGHT JOIN has not yet been
added, so the result of a RIGHT JOIN is currently the same as an INNER JOIN.
FossilOrigin-Name: 415abd6731b8e8a605adabfa6066c8a852a8531c300df41325d5f7e75cae5a70
if X is marked has having come from an ON or USING clause of a LEFT JOIN, then
be sure that all subexpressions of Y, not just the root node of Y, are
similarly marked. Otherwise, if Y is an AND operator, it will be split up
during WHERE clause analysis and the subexpressions will not get the special
treatment needed by LEFT JOIN ON/USING clauses.
Fix for ticket [66e4b0e271c47145].
FossilOrigin-Name: 69f9eb7343a416c5ab426c8e1b9f0ae576544b4ccc5d87f5481c8ff884f696e1
table that is in a LEFT JOIN, be sure to set the correct Expr.iRightJoinTable
value. This value does not appear to ever be used, except inside of a single
assert(). But it is good to set it correctly, nevertheless. This fixes
ticket [7929c1efb2d67e98], which as far as I can tell is completely harmless.
FossilOrigin-Name: ef604882a275d3d5ebd4d5a08e3fe43e148f169b7d5c3a81464fbe7f54f3582a
by disallowing query flattening if the outer query is DISTINCT. Without this fix,
if an index scan is run on the table within the view on the right-hand side of the
LEFT JOIN, stale result registers might be accessed yielding incorrect results,
and/or an OP_IfNullRow opcode might be invoked on the un-opened table, resulting
in a NULL-pointer dereference. This problem was found by the Yongheng and Rui fuzzer.
FossilOrigin-Name: 862974312edf00e9d1068115d1a39b7235b7db68b6d86b81d38a12f025a4748e
The WHERE clause of the partial index might not be true if the table of
the partial index is the right table of a left join. So disable the
optimization in that case. Ticket [623eff57e76d45f6]
FossilOrigin-Name: 3be19e1151af1850b65991edb82420f9412a7798dd756c86eaa9ffdde573263a
SQLITE_DBCONFIG_LEGACY_FILE_FORMAT option to sqlite3_db_config().
Fix for ticket [6484e6ce678fffab]
FossilOrigin-Name: 4d424f3047b48fc441475137f30a719d2f079390c86fe2617710ddfb05c5e240
expression that originate on the right-hand side of a LEFT JOIN.
Ticket [6710d2f7a13a2997]
FossilOrigin-Name: 500c9152daaf11cf69d778aa8592175f6088337c6667c59af6df3a24cd81eb0e
using -DSQLITE_MAX_SRCLIST=n). The maximum number of tables in a join has
always been 64, so this is not a real constraint on capability. Limiting the
size of a SrcList prevents DOS attacks (discovered by OSSFuzz) using crazy
nexted CTE joins.
FossilOrigin-Name: 7cac614d5df55eb092b863163483b6782b942b21bd15fd787576fef5619fa849
incorrectly applied in some cases where the WHERE clause of the query contains
a filter expression of the form "lhs.x IS NOT ?".
FossilOrigin-Name: 1fdaf2c34431adcac1c7ff29aae0623c4cbaa6a7f38e843c786bd407d8b3e730
incorrectly applied in some cases where the WHERE clause of the query contains
a filter expression of the form NOT(x AND y). Ticket [1e39b966].
FossilOrigin-Name: 38d319c153641ea4138fab2d5a47c31a86f57a071a1e1c299ca54c980cfb2b60
in the LEFT JOIN strength reduction optimization of check-in
[dd568c27b1d76563].
FossilOrigin-Name: e88cf3d4df64097ebc19aae464b88d0faf9b7d4c30d057042b582d78327e7ad3
check-in [dd568c27b1d76563]. The sqlite3ExprImpliesNotNull() routine was
mistakenly assuming that a CASE expression must always be NULL if contained
any reference to a variable that was NULL.
FossilOrigin-Name: cf171abe954a5f25262161dd69f2e8cecdbf9446c3f6b298201507dbc743567e
can be NULL even if that column is labeled with "NOT NULL".
Fix for ticket [892fc34f173e99d8].
FossilOrigin-Name: 483462682d3a57fb9dd85b4772596e9738f1694a454b8ebbc480b9452733e88d
does not currently work. Further fix for ticket [cad1ab4cb7b0fc344].
FossilOrigin-Name: 44b21e35c92137cc519d0cc87c627cc531d0bd442a7b9a7356fa2c6bc5f70fb6
the substructure of the TK_IF_NULL_ROW operator. This is a continuation
of the fix for ticket [cad1ab4cb7b0fc344].
FossilOrigin-Name: 941d8142b7c9a96ff143d1add3c86cf42d61fd08e532d400dac555f23eadbcfb
operators (that result from a prior flattening of a LEFT JOIN) are updated
correctly. Fix for ticket [cad1ab4cb7b0fc344].
FossilOrigin-Name: 92c178507df553e4f1110342c8f9b11b3ee37989e1d634fcaccabf657befa22f
Add a test to ensure that future versions continue to accept this non-standard
syntax, to avoid breaking legacy applications that use the undefined syntax.
FossilOrigin-Name: 824dde7fc48dbca6d6c956c4eb79bbfa2d139ee5
