than using a custom loop. Performance improvement, size reduction, and
complexity decrease.
FossilOrigin-Name: 351dbbc2bf0b23efdc625ddaa5dc2239cf2990addf071a04bd41612b341de8c8
an UPDATE of a view specifies a rowid, then return NULL for the value of
that rowid. dbsqlfuzz 7863696e9e5ec10b29bcf5ab2681cd6c82a78a4a.
FossilOrigin-Name: c7896e88850669e18e89d44c4169d4f4a5d4b904bea6ccb2ac64f93b6d348a42
check-in [2c56b984a0bd3be5]: only disable one-pass if the WHERE clause
contains a subquery. Allow subqueries in the SET expressions.
Fix for performance problem reported by
[forum:/forumpost/8ab195fd44e75ed0|forum post 8ab195fd44e75ed0].
FossilOrigin-Name: 42916af9fc0f379a608a08db894400bd735a28e26ab1ffd604d1fddfbdb3ec0c
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 the WHERE clause, since if the subquery is hidden behind a short-circuit
operator, the subquery might not be evaluated until after one or more rows
have been updated. Fix for the problem reported by
[forum:/forumpost/0007d1fdb1|forum post 0007d1fdb1]. This is the same
problem that was fixed by [73f0036f045bf371] only for UPDATE instead of
DELETE.
FossilOrigin-Name: 2c56b984a0bd3be5ec326a2109ea7b8f1d4ef63c8fc325caac9663cf2479eaff
wrong level. Instead use the SF_UpdateFrom flags on the Select object.
FossilOrigin-Name: 78723a9a7e72b42d28fc5645661da17f20cedcf864819b861800ad9340007be1
cruft than the coroutines-exp1 branch, but still does not work. Checked in
as a work-in-progress.
FossilOrigin-Name: e2318a30bf6ad2aeb4c4cb29661bc24ff78eb51bf07decc4b8da1ecac0015ef0
checking on non-STRICT tables. Specifically: (1) Columns with TEXT affinity
should not contain numeric values, and (2) columns with numeric affinity should
not contain text values that can be converted to numeric.
FossilOrigin-Name: 8b1e7f0524637728cebe81c7d3ff8ad8a5a55782eac6409b425dad538024f596
the designator from VdbeCoverageNeverTaken() to VdbeCoverage(). Test case
in TH3.
FossilOrigin-Name: 988a2a759f2b9da0e287e65306039b7a3e2b5aac3d31fe15cbb30d30ea6caf71
similar) since the functionality has how expanded to include data structures
beyond SELECT statements. Should not affect deliverable builds.
FossilOrigin-Name: 393fa32e188a017f431372b54037cb31e885030542f00d0bfd59da9d9db5c014
a RETURNING clause. See [forum:/forumpost/793beaf322|forum post 793beaf322].
FossilOrigin-Name: a818ba2ed635b91e279dde44236fc7446a33db2b46c9409b67021248c01bf4e5
to save memory in the common case where the column has no DEFAULT clause.
FossilOrigin-Name: 8646547e54211d44c415663c33775c4268550f8332949c4731a4bb6ec9cc663a
CTE name resolution problem described in
[forum:/forumpost/8590e3f6dc|forum post 8590e3f6dc].
Test cases for both problems added.
FossilOrigin-Name: 5614279daff5007d6e047c5c1b3cc82ba80a5c91c529525b0fe68b79ee82dd2c
the rows in an UPDATE FROM, make sure the first table is really the table
being updated, and not some common-table expression that happens to have the
same name. [forum:/forumpost/a274248080|forum post a274248080]. More
changes associated with CTE name resolution are pending.
FossilOrigin-Name: 0f0959c6f95046e8e7887716e0a7de95da18d1e926ab1f919527083a56541db5
UPDATE FROM of a virtual table.
dbsqlfuzz aa03237ef7c4a028c7cdaf8bbcde2b62e2bcd36e
FossilOrigin-Name: 49eac38926b3391b185d20fae6588c213f7f020f028173d4a4aa3c7a62b94140
SQLITE_ALLOW_ROWID_IN_VIEW compile-time option to restore legacy behavior
in case somebody actually needs it.
FossilOrigin-Name: 14b1d56ef84b0e62b7f9c4e5f7f985ca10e770c8db59f54004ad892c2a2dcbfb
