RIGHT JOIN as that leads to problems, as shown by
dbsqlfuzz a644e70d7683a7ca59c71861a153c1dccf8850b9.
FossilOrigin-Name: f113eebdbe68246fd38d640b0cdf0fd73ab5d2abad9226274dfa2e41fe286bf0
a GROUP BY since output terms that are no covered by the GROUP BY are
indeterminant.
FossilOrigin-Name: 28ba1fec4519e7ca9466f1a2f787c905f2cf880d38a004639f99f948e46a51e7
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
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
expressions within an aggregate query with GROUP BY. This implements
enhancement request [99378177930f87bd].
FossilOrigin-Name: b9190d3da70c41717eb188474fd225ee43d0b46646e1b03de5967bd332553870
a compound then all arms of the compound must have the same affinity.
dbsqlfuzz 3a548de406a50e896c1bf7142692d35d339d697f.
FossilOrigin-Name: 1ad41840c5e0fa702ba2c0df77a3ea126bd695b910b5d1271fa3129c38c58f5f
2MB on Windows, as we have observed that Window10 will sometimes bluescreen
when operating on very large sparse files.
FossilOrigin-Name: d39ffd2abadcc85c46ba17612f9f575005b4818e18bf39362b8ee574837cfad9
SQLITE_DBCONFIG_DEFENSIVE mode is enabled. This is a security
enhancement inspired by the question in
[forum:/forumpost/2b9cc3dae1f1e5f6|forum post 2b9cc3dae1f1e5f6].
FossilOrigin-Name: 1d81381e8f5db5d7064cc313b8544ca3cb1ca9e8cd61e71368a2d2e598befc9c
