to use more than SQLITE_LIMIT_COLUMN columns and raise an error.
Also include some unrelated compiler warning fixes.
FossilOrigin-Name: d7729dbbf231d57cbcaaa5004d0a9c4957f112dd6520052995b232aa521c0ca3
than using a custom loop. Performance improvement, size reduction, and
complexity decrease.
FossilOrigin-Name: 351dbbc2bf0b23efdc625ddaa5dc2239cf2990addf071a04bd41612b341de8c8
smaller and about 1.8% faster overall according to test/speedtest.tcl.
FossilOrigin-Name: 8be956383e0344fb613ec2e56fce7b518f439ae34bf9ddb424de2bd9b31c9889
in a separately allocated Subquery object. This reduces the memory requirements
for SrcItem and makes the code run faster. It also provides an expansion path
for subquery processing that does not burden simple queries. The current
checking mostly works, but there are still issues that need to be tracked
down and fixed.
FossilOrigin-Name: 8ff5dda8448d7e1a533d7f27db2573ce68fa9956b9d9847ced45e83c1f06bab0
SQLITE_LIMIT_COMPOUND_SELECT, even if the VALUES clause contains elements
that appear to be variables due to the use of double-quoted string literals.
[https://issues.chromium.org/issues/358174302|Chromium issue 358174302].
FossilOrigin-Name: 670beb133eb203065a75022f0c6db7c605a4e0e22c8ef6d6b4724be2663ff3dc
xfer optimization for tables with CHECK constraints. However, the xfer
optimization is required for correct operation of VACUUM INTO on tables that
contain generated columns. Fix this by ignoring CHECK constraints when
qualifying the xfer optimization while running VACUUM. Problem reported by
[forum:/forumpost/3ec177d68fe7fa2c|forum post 3ec177d68fe7fa2c].
FossilOrigin-Name: a6e26e778812c8409fca77183e24d3b70189c4d02fce10c7e74cd4ccc8c8ea97
constant functions. So far the enhancement only applies to the multi-row
VALUES clause, but it could possibly be applied in many other places.
FossilOrigin-Name: c9e0488c6c0135932b6e76b0f3f3acd69ef65327e0a54daa59777f35da1aef26
ON CONFLICT for each index is active. Do not issue an error, since that might
break legacy queries. But ignore the redundant ON CONFLICT clauses to prevent
problems such as described in [forum:/forumpost/919c6579c8|forum post 919c6579c8].
FossilOrigin-Name: d0ea6b6ba64dba9d68c2b391ccf1171ea96fcdd7409dafdb2b697accb00246b8
all inspired by [forum:/forumpost/dc3b92cfa0|forum post dc3b92cfa0].
(1) Do not allow a RETURNING clause to trick the code generator into thinking
that the view being updated has an INSTEAD OF trigger.
(2) Generate all result columns for a view in a DML statement.
(3) The automatic covering index for a view should cover all result columns
of the view.
FossilOrigin-Name: c8bedef0d61731c29ae34de1594222d15b578f9e2cddbbd5b74fb3059644fe0f
in place of the expression that is being indexed. This particular check-in
mostly works, but there are still issues.
FossilOrigin-Name: 2e8d4fd4cfd9e82f33c707ba246fe2bb3ca01762cf5ac5905058fbc7adf0abe7
db and ptr parameters are guaranteed to be non-NULL. Use this where
appropriate to save more than 2 million CPU cycles on the standard
performance test.
FossilOrigin-Name: e5eaa80e81fdf86f2875a912b880272b8d099b82b08e945a7988c5dd0fe9d6b5
a separate allocate for the base object and the array of IDs). Also permit
an IdList object to store an Expr pointer together with each name.
FossilOrigin-Name: 40f3c95871e6f40f287ef2756abafb8fc56dffdd0af69436e5c7d8e95022d94e
similar) since the functionality has how expanded to include data structures
beyond SELECT statements. Should not affect deliverable builds.
FossilOrigin-Name: 393fa32e188a017f431372b54037cb31e885030542f00d0bfd59da9d9db5c014
INSERT statements. This is all debugging code. There are no changes to
release builds.
FossilOrigin-Name: f3084122039bcb30c8617f5f432009a49be8b488235850a1f10ef862c91560b2
drh