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
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
as this can confuse RIGHT JOIN. Fix for the problem reported by
[forum:/forumpost/8e4c352937e82929|forum post 8e4c352937e82929].
FossilOrigin-Name: cab9b4cccd13bf0ab2bc38dc9a9c04ddd34e29c65ab6aef07b6bb3c31a43bece
would leave both EP_InnerON and EP_OuterON constraints on the same join term.
FossilOrigin-Name: c585d6a4678b04f4cedc08852d01c44cdf52ae2c8ccd1174c3d5a395088bf528
needed, so that if it is not needed, not useless work is performed.
FossilOrigin-Name: 16bf350683fd6ac906dbd02b21fb8bf1b1014ed05594cacf108645acd383ae65
subroutine used to matrialize a view. This does not change execution but
does make the byte code a little easier to read.
FossilOrigin-Name: cebd4fd606f967de527cff79df8e80e16d06eec257939322f16d21303868fb4d
so that the whole lot can be copied all at once. Faster and smaller code.
FossilOrigin-Name: 5341d4bbe9a943f9cdbbdea829e18f108e98972ebb706396c50fc62fcc6a6328
seems to work the same as PG. The code is chaos, however, and needs some
cleanup.
FossilOrigin-Name: 6f9c0b07aadc5189c65c3ee4e6938aac10fc0d98f1cb06980f5e5d7b0308f237
tests fail now due to extra columns appearing in the expansion of "*".
FossilOrigin-Name: c86804917e3fffcf0c19bbf11875667f7968275210fc768e650826bd9c87a5d2
sqlite3ExprIsTableConstraint(), not sqlite3ExprIsTableConstant(). This fixes
many problems, but still an error persists in join7.test.
FossilOrigin-Name: 10bf0e613809f71cc1a47ad40b517e2a66671212a6464e179c9d377e8b70d499
check-in [664b461bb5063d980] and reported by
[forum:/forumpost/0d3200f4f3bcd3a3|forum post 0d3200f4f3bcd3a3].
FossilOrigin-Name: 7ca3456c00998a429418ff29cf251b381586b330b88344c94a40c5df0b71da85
of an OUTER JOIN even if the OUTER JOIN is in parentheses. Prototype code
only.
FossilOrigin-Name: c3a427575fe71de3061495059e253c72c7213e2925ee2873e4f59fc73bfae103
distinguishing between "subquery" and "join" and using consistent names
across EQP and bytecode.
FossilOrigin-Name: a2d3ee92420ec564e31eb0005367cf7ff3d00bfaed5a98ffdbe17c91c95d9d97
Other code improvements manually imported from the right-join-paren branch.
FossilOrigin-Name: cd8272fc2a34d1b245fd95208b9b601266ee7d2ff0f5ce52d03752f2c4e852a2
to USING converter. This avoids NULL pointer dereferences further along in
the code.
FossilOrigin-Name: 0ccb224e13ad44c7e1a3aa186821a929faabc0075fe15799476c00d9a92e9d91
of two or more joins where one of the joins to the right-hand side of the
list is a RIGHT or FULL JOIN.
FossilOrigin-Name: 9ffc2b231956cde1bc90519aa174b0e2dc30ef671ed745f4f3ffa9fbb7ffab4b
drh