corelated values inside an aggregate function within a subquery.
[forum:/forumpost/79cf371080|Forum post 79cf371080].
FossilOrigin-Name: d8259877eaa962e6f90675790d3770ef02bd1a5d86d319cd8c1834710df844c4
queries, which is here fixed. Problem reported by
[forum:/forumpost/b405033490fa56d9|forum post b405033490fa56d9].
FossilOrigin-Name: dc9f025dc43cb8008e7d8d644175d8b2d084e602a1513803c40c513d1e99fea4
historical datatype ("INT", not "NUM") for a table created as follows:
"<tt>CREATE TABLE t1 AS SELECT CAST(123 AS INT) AS value;</tt>".
FossilOrigin-Name: a0e54fe2058a4ac1e794b2491e424c60dfa42c6781b1cfd83c5db65c28c11c71
requested by ticket [99378177930f87bd] - that can cause an incorrect answer
if an aggregate subquery has a GROUP BY clause, and that GROUP BY contains a
term that is not in the result set, and the outer query makes use of expression
indexes. Problem reported by
[forum:/forumpost/a68313d054|forum post a68313d054].
FossilOrigin-Name: e06973876993926fd56181281d04b8dd504c689abf883fa21a5721cc1d478ea8
the optimization of check-in [41c27bc0ff1d3135], always insert the
TK_IF_NULL_ROW expression nodes, even for TK_COLUMN expressions, as
the TK_COLUMN might be a column from an outer query and hence still need
to be NULLed out. This fixes the problem described by
[forum:/forumpost/26387ea7ef|forum post 26387ea7ef].
FossilOrigin-Name: 198b3e33dcfd74c7ba6abcf789ee81dfed464a50ebf15c8edeff349d36789fca
sure to remove the EP_Skip and EP_Unlikely flags from the result set expressions
that get nulled-out. dbsqlfuzz bf1d3ed6e0e0dd8766027797d43db40c776d2b15.
FossilOrigin-Name: 21aec65e5e2a01e58dd0bb8c8b9b29b8414373b53353fc7ca80a152fdd27566b
check-in [1ad41840c5e0fa70] because it is no longer needed after
the enhancements to compound query processing in check-in [27655c9353620aa5]
This resolves the performance regression reported by
[forum:/forumpost/bcc4375032|forum post bcc4375032].
FossilOrigin-Name: aa6bd6dff751223e302575c60f335707e4bb820bff716cab3706b564e18ed7ed
optimization if the subquery is an aggregate or is distinct, but allow it to
be an ephemeral subquery. Do not omit columns that are used in the ORDER BY
of the subquery.
FossilOrigin-Name: 6b1a1f374d1372f11f5420d99645b218867100bf070bd3a8885bf5f00c189dff
columns NULL instead. This optimization potentially resolves the enhancement
request described by [/tktview/baa5bb76c35a124c|ticket baa5bb76c35a124c].
FossilOrigin-Name: 5dec3cc0225296a043d17f73126d477d90a604f82b3180628176d8f950adbce8
tagged with M10d_Yes and thereby prohibited from participating in the
query flattening optimization. See
[forum:/forumpost/1d571c02963355ed|forum thread 1d571c02963].
FossilOrigin-Name: 66f29c403d28630bfaea9124bd63ee4a047b1fe4a7e27dc5d10d67d1601b15e0
N-th call to sqlite3ProgressCheck(), where N is the progress handler step
count. Also fix faulty asserts exposed by the ability to interrupt in the
middle of sqlite3_prepare().
FossilOrigin-Name: 05461651599bb490ac6cfd893645dabab9cccedc6adcce15aee2487b2ea6027a
statement preparation by invoking the progress handler at strategic points
during sqlite3_parpare(). This experiment shows that sqlite3_prepare() might
leave the resulting prepared statement uninitialized following an interrupt.
FossilOrigin-Name: 79636f2d80aee70832913a78933da2a7e30cc037810b93903ebbc1925ea93fef
as the underlying table if such is available and is consistent with
the computed affinity of the column.
[forum:/forumpost/7fb1fe9dcf310ef5|Forum thread 7fb1fe9dcf310ef5].
FossilOrigin-Name: 497a98363fd1ed079544620ec5d0883f987ed03013131542741c93d7568e8568
RIGHT JOIN as that leads to problems, as shown by
dbsqlfuzz a644e70d7683a7ca59c71861a153c1dccf8850b9.
FossilOrigin-Name: f113eebdbe68246fd38d640b0cdf0fd73ab5d2abad9226274dfa2e41fe286bf0
never tries to convert integer to real or real to integer. The affinity is
only used internally - it is not possible to create a table column with this
affinity. This affinity is used on subqueries and views that are built off
of a compound SELECT and where the datatype is controlled by a CAST expression.
dbsqlfuzz c9ee6f9a0a8b8fefb02cf69de2a8b67ca39525c8
FossilOrigin-Name: 44135d6ea84f7ba6b36549954b38a8bc048d5ffea5a9779e35950afa4eb2dfb2
a compound with different result datatypes on two or more arms of the compound,
then the overall column type becomes BLOB (ANY).
FossilOrigin-Name: 6ebb178c6b688ebd632e91a5ec4c748567833037c679ab3d72fb770deb230fe1
the materialization of a view, as the affinity can be undefined for a compound
query. This passes all TCL tests, but shows failures in the TH3 tests derived
from [forum:/forumpost/6f842bc5b2dadcb2|forum post 6f842bc5b2dadcb2], presumably
because the WHERE clause of the query uses constraints of the form
"source_crs_code='8675'" instead of "source_crs_code=8675". Perhaps further
changes on this branch should reimplement affinity on joins in cases where
the affinity is unambiguous.
FossilOrigin-Name: fe5a77bcc4de8f49cc4fe6bd2e2e1f31da8d3bc84120daaa99eb853b06291d15
give that column no affinity rather than NUMERIC affinity. This is because
casting to numeric preserves real values that could be integers but numeric
affinity does not. By using no affinity on the column, we make the behavior
consistent if the subquery is implemented as a co-routine or is materialized.
FossilOrigin-Name: ece07d091c2ef3367a914187e0b6512c1f2390b8c34844536ad50e88c7e8c2f2
wrong level. Instead use the SF_UpdateFrom flags on the Select object.
FossilOrigin-Name: 78723a9a7e72b42d28fc5645661da17f20cedcf864819b861800ad9340007be1
Update test cases to accommodate the more aggressive use of co-routines.
FossilOrigin-Name: 9243e850ae656d16adc8f0e5c4dcf3dcf476312cee192c39c38685fc437ccbbd
cruft than the coroutines-exp1 branch, but still does not work. Checked in
as a work-in-progress.
FossilOrigin-Name: e2318a30bf6ad2aeb4c4cb29661bc24ff78eb51bf07decc4b8da1ecac0015ef0
if one or more columns uses a collating sequence other than BINARY.
See [forum:/forumpost/3824ced748baa808|forum post 3824ced748baa808] and
check-in [346a3b12b861ce7b].
FossilOrigin-Name: adbca3448e2099f0d6149a073978f230ed9a92a2f384779879ef89e672231bcf
drh