the built-in printf(). This is an effort to avoid a reported
timeout on a (ridiculous) query generated by OSSFuzz.
FossilOrigin-Name: 371f9b88387a44a5f820279d79733d1deb7eafc72f320ec47a11679bbdbb49ef
not just a reference to another column, as a real expression is necessary for
the indexed expression coverage optimization to work properly.
[forum:/forumpost/07b36e3899a9ae21|Forum thread 07b36e3899a9ae21].
FossilOrigin-Name: 40549bacb3923e439627b0103bedd7da30258b69a46960040f7176e060f51f2f
Parse.pIdxEpr list as part of indexed expression coverage. Debug and
testing changes only - no affect on production builds.
FossilOrigin-Name: 4dc438a951bdbe27fbd5ee7cfb907e30ec0efbf8ce02109f18997cc221e0ad3b
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
column of the form "CAST(expr AS NUMERIC)" do not give that column NUMERIC
affinity. NUMERIC affinity always goes to an integer if able, but a CAST
to numeric is a no-op if the input is a number. So the two are not equivalent.
FossilOrigin-Name: f0325359d5795237b79f90f21b42d7d942c7e918137cb0231d404365d3041e81
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
doing a DISTINCT query against a virtual table with an OR term in the
WHERE clause and where the ORDER BY clause has 64 or more references to
the result set. [forum:/forumpost/dfe8084751|Forum post dfe8084751].
FossilOrigin-Name: 04af7ef77043702f93cbff23548610759786893bd3d4d6fc08181e1e249c6663
drh