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
file (which can only occur if the file is corrupt) and fail with SQLITE_CORRUPT.
FossilOrigin-Name: cd7a44124558ea6a43c89b1cba4402d7bf6a6ccb83be0eeb7dd01b56933bca73
the designator from VdbeCoverageNeverTaken() to VdbeCoverage(). Test case
in TH3.
FossilOrigin-Name: 988a2a759f2b9da0e287e65306039b7a3e2b5aac3d31fe15cbb30d30ea6caf71
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
in the presence of RIGHT JOINs also apply to the use of WHERE clause terms
to manufacture automatic indexes. This fixes a problem identified by
[forum:/forumpost/51e6959f61|forum post 51e6959f61].
FossilOrigin-Name: 342c501f532523347e6c339351e02043dd6ee9e11a291224b65ea72bd6c2ba40
as this can confuse RIGHT JOIN. Fix for the problem reported by
[forum:/forumpost/8e4c352937e82929|forum post 8e4c352937e82929].
FossilOrigin-Name: cab9b4cccd13bf0ab2bc38dc9a9c04ddd34e29c65ab6aef07b6bb3c31a43bece
Proposed fix for the problem reported by
[forum:/forumpost/3d9caa45cbe38c78|forum post 3d9caa45cbe38c78].
Additional works is needed as not all cases are covered.
FossilOrigin-Name: 08af1fe27ebd0edf6e0f1ac477deea033e7f7c813f1016b75196836daf02d2e4
an inner-join and outer-join ON-clause constraint (or equivalent) on the same
term of the FROM clause.
FossilOrigin-Name: f6c4fb48b65c2e8659aa0a1119c330e8bad5e42b2db2030850bfc9c04afef5c8
would leave both EP_InnerON and EP_OuterON constraints on the same join term.
FossilOrigin-Name: c585d6a4678b04f4cedc08852d01c44cdf52ae2c8ccd1174c3d5a395088bf528
since the index is partial, some rows will be omitted from the scan, and
those rows will subsequently be picked up by the no-match logic in the
right-join post-processing loop.
[forum:/forumpost/c4676c4956|forum post c4676c4956].
FossilOrigin-Name: 615c0026119f7870c3b6ef9dcb57ce4ecf5acedea3e2b5cfc25aa450eb8f17a0
sqlite3ValueFromExpr() routine.
[forum:/forumpost/800eecf5e6cdc3f4|Forum thread 800eecf5e6cdc3f4].
Test case in TH3.
FossilOrigin-Name: 3f6a442099b8264cc788e8aa2b12cc583439a5263c4fe433fd22b7af1be2458e
the right operand of a RIGHT JOIN, since this can cause problem if the
constraint implies a not-NULL value for one of the columns for the left
operand of the same join. See
[forum:/forumpost/206d99a16dd9212f|forum post 206d99a16dd9212f].
FossilOrigin-Name: 4a31b7942a15c9c4363477365784d6d4ac5b1bbe8ff8aeaf2dd3d6532bf8bc96
used when processing a RIGHT JOIN. Fix for the problem described by
[forum:/forumpost/087de2d9ec87305b|forum post 087de2d9ec87305b].
FossilOrigin-Name: 5a9465dcc0c23fc2c66cd4898bcdfd5086fe4c71ec19a95db7221fdf7c0bbbbd
