the right moment - not too early and not too late. Fix for the problem
reported by [forum:/forumpost/3902c7b833|forum post 3902c7b833].
FossilOrigin-Name: 3869fd9a2b9483cbbf83d8f369c1744abc42f12e63abba402be35dd7e136161c
FROM clause terms that are even further to the right. Fix for the issue
identified by [forum:/forumpost/5cfe08eed6|forum post 5cfe08eed6].
FossilOrigin-Name: 4be0c60e38edc5d5bfd72bb35a3c91c55240b4e6313a40614beb60f1ab9d9f4c
of the join, just convert the ON clause to an ordinary WHERE clause term,
in order to be compatible with older versions of SQLite. See
[forum:/forumpost/687b0bf563a1d4f1|forum thread 687b0bf563a1d4f1] for details.
FossilOrigin-Name: 2b6ebba26d936ae7b9acf7d4bd15e82cbfabda22e1044b3dd838c7b07095100e
for LEFT JOIN versus RIGHT JOIN that protect legacy behavior.
[forum:/forumpost/e90a8e6e6fa652ac|Forum thread e90a8e6e6fa652ac].
FossilOrigin-Name: 2c586060a016f5481bad29bfb8f4ac4e1204075afdd0fa1851fbbcf2abda4893
the index might not be positioned on the correct row when running the
the right-join no-match loop.
dbsqlfuzz 39ee60004ff027a9e2846cf76e02cd5ac0953739
FossilOrigin-Name: 2277f9ba7087dd993ac0f4007c523aa9cf74dba187f53af03d8c164886726fee
join that is an operand to a RIGHT JOIN. Fix for issue identify by
[forum:/forumpost/c06b10ad7e|forum post c06b10ad7e].
FossilOrigin-Name: 9d17233c7d98bf25c1a518d067e778708b3db6d6302edd8d7e376ba0ba4f1c30
reuse the same ephemeral cursor of a list subquery when that subquery is
reused, as it does not work in cases where the list subquery is used both
for lookups and for scans.
FossilOrigin-Name: 12ee29d632ae4b585ef6bc07d3289d00c121268945dffd5673b251d95874e3f8
answer. See [forum:/forumpost/41cc3851d8|forum post 41cc3851d8] for the bug
report.
FossilOrigin-Name: 02b24863e6dc617c9260f79292a96b7c861d088268e77fd17204570515eb792c
equivalent to IS and IS NOT, respectively, for compatability with PostgreSQL
and hence standard SQL.
FossilOrigin-Name: db27611e172102483eaede3981d473e3d5bf93d98bc68f480398b1573876349d
chekc-in [f237e1d8cc41b937]. The bug was detected by dbsqlfuzz
test case 4c5e3e89bc251d28378be88233f531b84ec66901.
FossilOrigin-Name: 764b71267e0b31ff7eaf2a0def7526a1a02dce4d5b456dea060d97ed342efdd1
place if it encounters a NULL key. Fix for the bug described by
[forum:/forumpost/2482b32700384a0f|forum thread 2482b32700384a0f].
FossilOrigin-Name: 6eda9b1a7784cf6d58c8876551f67ab98e78a08e726a0579d4def5ba881985bb
logic for a subquery on the right-hand side of an IN operator. The code still
needs simplification.
FossilOrigin-Name: a193749730d6cfba617f2a64e7254c78f92bbf29b109c19055fc33f6cc643d4c
the use of that expression into a reference to the index. See
[forum:/info/7efabf4b03328e57|forum thread 7efabf4b03328e57] for details.
FossilOrigin-Name: a8da85c57e07721dc1c918d67433d6c99ce48421e369123cc3194d855e55f7e8
a right-hand side subquery is used as a constraint that needs to be processed
by the RIGHT JOIN non-matched logic.
FossilOrigin-Name: bb2798be3fb5737827eec505db2d4c8cb510d227d98fc26ce748bf2da7e8b382
able to reuse an IN operator that has an invariant subquery on its right-hand
side while coding the non-matched loop of a RIGHT JOIN.
dbsqlfuzz 19f1102a70cf966ab249de56d944fc20dbebcfcf
FossilOrigin-Name: 56dd3065469e49320b13af039471b3f0b85e6f7368cfd97b1cdc0cf8fa8e1956
tests fail now due to extra columns appearing in the expansion of "*".
FossilOrigin-Name: c86804917e3fffcf0c19bbf11875667f7968275210fc768e650826bd9c87a5d2
check-in [664b461bb5063d980] and reported by
[forum:/forumpost/0d3200f4f3bcd3a3|forum post 0d3200f4f3bcd3a3].
FossilOrigin-Name: 7ca3456c00998a429418ff29cf251b381586b330b88344c94a40c5df0b71da85
distinguishing between "subquery" and "join" and using consistent names
across EQP and bytecode.
FossilOrigin-Name: a2d3ee92420ec564e31eb0005367cf7ff3d00bfaed5a98ffdbe17c91c95d9d97
introduces some new faults in the tests, probably due to something
unrelated.
FossilOrigin-Name: 95b242d4c2fed7c713299565ac1010f8a7534a5695589e87d5a0204c7bf5f3dc
right-join body subroutine from an issue to an optimization opportunity.
FossilOrigin-Name: 829d49f27c041651ffeadc1397e4dd87a9994c9290e13b93542dbd2c514769cd
the join8 test module, with tests that deliberately fail in order to remind
us to fix the issues.
FossilOrigin-Name: 2c4ee723f4d0591d09776adfb82246bfa89153ab390b8b3f1878d1cdc43d68c8
remove the "or unsupported" clause, because we now support all valid join
types.
FossilOrigin-Name: ab0a0562dd3594cf50ee56f6b3a5847fa5dcadf69146d560e3e7a95651b8f405
constraints on outer joins, and (3) ON/USING clause constraints on inner
joins. Formerly, there was no distinctionb between 1 and 3, but RIGHT JOIN
needs to know the difference. Make RIGHT JOIN aware of this difference and
add test cases.
FossilOrigin-Name: 0f6f61c3664cc87209c2a6f9b6df3a750d1510723fcde209c33db8feaf48bcf3
automatic indexes must be WHERE_IDX_ONLY, but the RIGHT JOIN post-processing
does not know how to work with an index-only scan.
FossilOrigin-Name: beb4401dc09fb68e85ddcf3f99598527691535d0eb7693168f440e5a5a076e3f
that are to the left of a RIGHT JOIN, to avoid other complications.
FossilOrigin-Name: cf00ebfc4b77f45ec466b0d57d7c22c7f48acab19e4e55b168eb4b53f390d887
make sure all its columns are flushed to NULL when it finishes so that
they appear to be NULL during the RIGHT JOIN post-processing.
FossilOrigin-Name: f84b2beca719758979d7a5a63c3d16d5121a7518b3fbe5039af474a83dd569c2
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
IS NOT NULL constraints from the WHERE clause when operating on a LEFT JOIN.
[forum:/forumpost/031e262a89b6a9d2|Forum thread 031e262a89b6a9d2].
FossilOrigin-Name: 1a6328f2a5b4973094e5f85787145d652119822c86ec01a61f3f985c9d2903f2
(check-in [0057bbb508e7662b] about 16 hours ago), be sure
to clear the BTCF_ValidOvfl flag, since the overflow cache is invalidated
by the search on the last page. OSSFuzz issue 45329.
FossilOrigin-Name: 0021bebc162e001b788786703ce634e7b8fcd3976f7047a5956e82140791e765
to avoid violating invariants associated with Expr nodes. See
[forum:/forumpost/2024e94071ef1531|forum thread 2024e94071ef1531] for more
information.
FossilOrigin-Name: 5e0ed49b3d739d292f5df3e498449ae8f4357cbb83394181fb34f98ed8372707
[forum:/forumpost/0cd8e058bf|forum post 0cd8e058bf]:
When evaluating an multi-index OR, do not push down auxiliary WHERE clause
terms that involve subqueries into the OR-subqueries. Otherwise, the
covering-index optimizer might convert table-references into index-references
for the particular OR index that is active for the branch in which the
subquery subroutine is coded, and those index-references
will not work if the subquery subroutine is invoked from a different OR branch
that uses a different index.
FossilOrigin-Name: 61a1c6dbd089979cbeb8b0c0c5ee1ab1abcb466be1d21a3a851be73c27e67a6c
Make sure the query planner does not try to to both.
[forum:/info/50a1bbe08ce4c29c|Forum post 50a1bbe08ce4c29c].
FossilOrigin-Name: ad3ffa1a75a5a032ebb64d8e014ee0a85c5e44b732e4b11bd67f31a59e729b94
to cover the entire database. Fix for the problem identified by
[forum:/forumpost/3b9e894312|forum post 3b9e894312].
FossilOrigin-Name: 12c012162ce110a7a7fbbe853f422e23cb4ae10b45237727328c8f3315b70842
there is a RETURNING clause, since that optimization is not able to deal
with RETURNING. See [forum:/forumpost/595e132f71|forum thread 595e132f71]
for details.
FossilOrigin-Name: 1d3760a517b8bd2a6be82d2d5788945f49397cdc539fe28fd23e2c0c62a1dbe2
EXPLAIN and EXPLAIN QUERY PLAN do not affect the return value. Add test
cases to verify this. Add new test cases and requirements marks for
complete requirements test coverage on this interface.
FossilOrigin-Name: a6fbb7ba0583b3981e2d8b809006b902b3e97e516dbd3ab7d905c5ea73df2272
testing of the 'localtime' and 'utc' modifiers to date/time functions.
FossilOrigin-Name: f38071946ac2e5bb61e6c0620507e4c94464999ac700d86c1a704b94eb1c009a
SQLITE_ENABLE_PREUPDATE_HOOK is not defined.
Fix for test-case breakage from check-in [c006515ae6faff65].
FossilOrigin-Name: 937d3a45b3fef354dbdea2085fbb7d9c752a96e8ebb62f61931deb5a64132946
the main query into the various OR-term subqueries, do not push down slices
of a vector comparison, since the right-hand operand of the comparison might
have only been initialized in a different OR branch that was not taken.
dbsqlfuzz 80a9fade844b4fb43564efc972bcb2c68270f5d1.
FossilOrigin-Name: 9f67ad00cd38b7c5ec6d14b379e1a611777bbdf6901d843a80712ba7d94d6d33
algorithm so that it breaks at punctuation if it cannot find space. Always
wordwrap with --ww even if there is a .width setting for the column.
FossilOrigin-Name: 1b528e31f8c62797e0814568b520c0680ff23a2ee877ca6aa70a167d40ebdf80
if the table will be used to construct an automatic index or bloom filter.
dbsqlfuzz 787d9bd73164c6f0c85469e2e48b2aff19af6938.
FossilOrigin-Name: f8766231d2a77bb8b95726b514736d4c2d20b056f7fe60bdbc98ebf5e5b15ae9
[forum/forumpost/5b53cd851f66441f9|forum post 5b53cd851] for discussion.)
New output mode "qbox". New output options "--quote" and "--wrap N".
FossilOrigin-Name: 539cef5214446a7181614793e9cf323e95ba00ba0f888585b14b598dd2ff0808
[6a45d8fe8bfbc11a|check-in 6a45d8fe8bfbc11a]. See
[forum:/forumpost/8b39fbf3e7b5c278|forum post 8b39fbf3e7] for
the original bug report.
FossilOrigin-Name: 639fc7633bd740421d6b48617b9f68e6be525107e4049673fe720ea6158a393f
after the time-value. This has been documented since 2004, but has never
actually been enforced before. Also add new test cases for date/time
functions with evidence marks.
FossilOrigin-Name: 64fa9e8c87179211cec248e6dfd7578502e6e969a19e91a4f0e21ed9b972a6bc
check for NULL values and abort until after all key values have been
computed, in case one of the later key values involves some initialization
that is needed by a LEFT JOIN. Fix for the problem identified by
[forum:/forumpost/ab95010d410a0a55|Forum post ab95010d410a0a55].
FossilOrigin-Name: 4db5217a28ce767fa14ddfe51cf3ca25eceb72079d46a2fc00f7d6b8ae9abe0b
([00ec95fcd02bb415|check-in 00ec95fcd02bb415]) so that it works
for the case of 64K page size.
FossilOrigin-Name: f426874e005e3c23e8a00083b7c201408e072bca413e52bfc436da6483afb0cd
insertion into a generated column on a STRICT table.
[forum:/forumpost/fa012c77796d9399|Forum post fa012c77796d9399].
FossilOrigin-Name: 1ec44d55da2ced1a1b0b78b489caff628652464f5709ee827e35409eb20ea794
subquery has an ORDER BY clause and an OFFSET, NULL out the destination
register before starting the ORDER BY so that the register will be set
correctly even if the OFFSET is larger than the number of output rows.
Fix for the problem reported in
[forum:/forumpost/0ec80f12d02acb3f|forum post 0ec80f12d02acb3f].
FossilOrigin-Name: 9282bcde301cee2a5c3c068b5b0b7ce992c155ece894413a6a9a51a81e4133fd
but -> does not. This allows ->> to behave the same as PG and MySQL.
FossilOrigin-Name: 85f8170555ee0d4d28cb7e120a7062e9f64c331a936fdfa29fc0e67224eea7c6
returns NULL instead of raising an error if the first argument is not
well-formed JSON. Or if the first argument is not well-formed JSON and
the second argument is '$', then return the first argument quoted. The
"->" and "->>" operators are converted to use json_nextract().
FossilOrigin-Name: dc00f5286d26524b149de071490320afaa203fec5777b3eb813f07963614861a
except that it returns NULL if the argument is not well-formed JSON, rather
than raising an error.
FossilOrigin-Name: ed9956f5ddca68141eded81d5362847db603257329801622c4eb3b0732112f14
2-argument SQL functions by the same name. Add new "->" and "->>" functions
to the JSON extension that are aliases for json_extract().
FossilOrigin-Name: c4e4e3a3fc5da0381ccb7930706e57d7831d87f9c63bafe49ae64117701e1cfe
and which is not always true. Fix for PoC #1 of
[forum:/forumpost/b03d86f951|forum post b03d86f951].
FossilOrigin-Name: c76a4c0b3cb625017ba09c8bccfcf1b5826df6873f1d3705d3345716079d5ec9
case derived from [562805cf488a455c]. Also add a test case to that prior
issue.
FossilOrigin-Name: 0dd6b5fccd554ebe4c0b081601863acd7b6ea81b51e14b508b23244f2a570e7e
uniqueness constraint, and it participates in an upsert on that other
constraint, ensure that code that checks for conflicts on the INTEGER PRIMARY
KEY is well-formed. Fix for the problem reported by
[forum:/forumpost/06b16b8b29f8c8c3|forum post 06b16b8b29f8c8c3].
FossilOrigin-Name: 2f09b51b1ff37bf98f958564cc1224968caa7e33147e6666b5c1ba20b2a7813b
of the shell that points to the specific part of the input line where the
error occurs.
FossilOrigin-Name: d4870c08893ea9984b1fa1c3a7d04893ad5ed4a2130e9287d169a306cc8ef0a4
See [forum:/forumpost/e0c7574ab2|forum post e0c7574ab2] for the bug report.
FossilOrigin-Name: 4711fb69547f4f17653ab116030c32fdcc2c836410349d1d025866ffc15704da
ORDER BY terms that contain COLLATE clauses as long as the specified
collation matches the virtual table. This is especially important for
UNION ALL since a "COLLATE binary" is added to ORDER BY clauses if no
COLLATE clause exists in the original SQL.
FossilOrigin-Name: 5c3d398d20b86a1558720e995eddf11403aec2d160590571fa9525fe8f6efff9
