try to reuse values from the result set if the result set has not yet
be computed. This fixes a bug in the recent deferred-row loading
optimization, check-in [c381f0ea57002a264fd958b28e].
OSSFuzz discovered the problem.
FossilOrigin-Name: 5d61e75f32de09c81dbe844443209f063cccb005d60b846900de5b023643fc3b
it becomes clear that the row will not come in under the LIMIT, then skip
evaluation of the other columns.
FossilOrigin-Name: c381f0ea57002a264fd958b28e4921cb9c9e73a10fb592f6bb64e6bc9bd16d39
whether or not a record may appear in the final result set before adding it to
the sorter.
FossilOrigin-Name: 71bf91c218334381b1b4bdba6a093e623b62e17f3e8550e154a11f0cb0b404f3
right table of a LEFT JOIN. Fix for ticket [4ba5abf65c5b0f9a96a7a40cd18b]
FossilOrigin-Name: aeb694e3f787f1f8b55650c17f90c197eee3f7f9b890a88f458c33e43009a082
be displayed, after all transformations, and showing the EQP iSelectId at
each level.
FossilOrigin-Name: ca34c2dd20ee071e6f8d60f91dbf474515a688ba57949143483da1641246cb25
that some required values may be loaded from the database after external
sorting occurs for SELECT statements with ORDER BY clauses that are not
satisfied by database indexes.
FossilOrigin-Name: ef74090a40ceaef2fd93a7613ec99a191ce986811c852e96f4a19719f18af4f0
contains an incorrectly placed ORDER BY clause. This problem is just an
assert() failure - non-DEBUG builds are not affected. Problem found by
OSSFuzz.
FossilOrigin-Name: 823779d31eb09cda5effe747d9adb35e600a52d4274226586437f674e7824d91
generated incorrect results. Reinstate the restriction (4) (with
qualifications) that was removed by check-ins
[b5d3dd8cb0b1e4] and [dd568c27b1d765].
FossilOrigin-Name: f08c1731b0b1dddcba190b094a35306a159713d3db939330f73075ff1d72c81e
not be a null row, then simplify the LEFT JOIN into an ordinary JOIN.
FossilOrigin-Name: 5b7abecc7ab8ccbbb8cb5e0f672e67625c2555ad03442efbf34cb395f5bb71a8
right, since by starting with the right-most column, the work done by
OP_Column opcodes is reduced.
FossilOrigin-Name: 8055e4f42446ceb5bcf752bbf41a73289c3ca759c56c9f779edc3d7f202b7881
within a scalar expression. This fixes a problem discovered by OSSFuzz.
FossilOrigin-Name: a4fa0581ba7cfd45fabe0198f55b3c2c8ee3ecfd2825aeed91116f44e77d760b
CREATE TABLE AS. This is a fix for ticket [3b4450072511e62] and a
continuation of check-in [ade7ddf1998190b2b63] that fixes cases of
ticket [de3403bf5ae5f72ed6] that were missed previously.
FossilOrigin-Name: 6b2ff26c25bb9da344add79c93fb3e49fa034a89b38ef56e08e18d21de61f707
a SELECT statement. This helps with debugging for tickets like
[de3403bf5ae5f72e] and [3b4450072511e621].
FossilOrigin-Name: 8f194008c3aaa4ef287200e37bc5278ba9c377a7091ee3f95bad66513226b083
on a TK_LIMIT node, for a small code size reduction and performance increase,
and a reduction in code complexity.
FossilOrigin-Name: 3925facd942c9df663f9b29b1e6f94f6be14af8c2b99eb691bfc836b4c220826
no function calls or subqueries. This is a partial reversal of
check-in [c9104b59]. Co-routines are still preferred if the outer
query has a complex result set, but for simple results sets, query flattening
is used. Check-in [4464f40ccd7] is completely backed
out due to this change.
FossilOrigin-Name: d17ef7d153058f7332b3fec421ade42c67e26b06f36fc1629e6799537a5afc5f
common table expression. This fixes a problem found by OSS-Fuzz. The
test case is in TH3.
FossilOrigin-Name: 6ee8cb6ae5fd076ec226bb184b5690ba29f9df8cfaef47aaf13336873b4c1f6c
restricted can no longer occur because of the more aggressive use of
co-routines.
FossilOrigin-Name: 4464f40ccd7c5553f4d44120ca6dac4e9445f08f083f7dcb3bd66b4413d818e0
