has the wrong affinity. dbsqlfuzz 65f5eb57f8859344d5f1f33e08c77ee12960ed83
FossilOrigin-Name: e95439119ac200cb47d0e277622f41ee7986b364487cd252b485ce5fa030d70f
(check-in [41c27bc0ff1d3135]), ensure that the OP_IfNullRow opcode does not
NULL-out a subquery result that was computed within OP_Once. This fixes
the problem problem reported by
[forum:/forumpost/402f05296d|forum post 402f05296d].
FossilOrigin-Name: 8fe13f7a5e5eb798189acb25a608df7a94c2f5cc83463331a048b779c7890c82
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
boundary even if the function that returned the value with a subtype is
buried down inside a larger expression. This fixes a problem identified
by [forum:/forumpost/37dd14a538|forum post 37dd14a538].
FossilOrigin-Name: e72661eb680ea707a839cb3d5cf6c7ef03706e7b40af1b84760147e59cd61a50
value, because we do not know if two different strings might compare equal
even if they have different byte sequences, due to collating functions.
Formerly, the hash of a string or blob was just its length. This could
all be improved. Fix for the issue reported by
[forum:/forumpost/0846211821|forum post 0846211821].
FossilOrigin-Name: 090304b870419acb5b05205a07fc75830b556928149f76a843cda526f77a6fc0
is on the left side of a RIGHT JOIN do not need to be in the ON clause. Add
new test cases and tags to associated test cases with the code.
FossilOrigin-Name: 18ee689de3d1ae43b05ca52e0b62c49442ebf68a88814a7c679e8856250a4b0d
sure to remove the EP_Skip and EP_Unlikely flags from the result set expressions
that get nulled-out. dbsqlfuzz bf1d3ed6e0e0dd8766027797d43db40c776d2b15.
FossilOrigin-Name: 21aec65e5e2a01e58dd0bb8c8b9b29b8414373b53353fc7ca80a152fdd27566b
available in testfixture, and to use no more than half the available cores.
FossilOrigin-Name: e0122d3863ed03e7bb64400d6561cbc824ecb14d228949ffde443069dbb4223a
floating point value has no fractional part.
[forum:/forumpost/d1387c3979c7f557|Forum post d1387c3979c7f557]
FossilOrigin-Name: 18de3a8e6b431a075143631eafdcf0e1b1a21868b417394c365d46d2feca10b5
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
columns NULL instead. This optimization potentially resolves the enhancement
request described by [/tktview/baa5bb76c35a124c|ticket baa5bb76c35a124c].
FossilOrigin-Name: 5dec3cc0225296a043d17f73126d477d90a604f82b3180628176d8f950adbce8
can happen if DQS_DDL is enabled. Follow-up to
[44200596aa943963]. dbsqlfuzz 54c9db85ed4af7055f5fd0d50877875c82b11d46.
FossilOrigin-Name: 2d2b91cc0f6fed8cb6f738dc7019047ce0f1e86b5eb8efa997095d08a32cbcb6
an expression index. Fix for performance regression reported by
[forum:/forumpost/e65800d8cb|forum thread e65800d8cb].
FossilOrigin-Name: 44200596aa943963bc6ca98b5d4fd5b9235d1109d8dfc1a75eeae353b4239142
"transaction" is confused and needs to be straightened out prior to moving
forward with this change.
FossilOrigin-Name: 4a145f07322d768a07619bed27e0390d50f3a01d07787b9296234a5ceb6f1218
STAT1 data, the query planner cannot make an accurate determination of
whether or not a Bloom filter will be useful. This fixes the problem
reported by [forum:/forumpost/56de336385|forum post 56de336385].
FossilOrigin-Name: e6ab96bd0b9efc51fd703bf7e92b079943ad9a3b92183d434adc11fb7d238afb
tagged with M10d_Yes and thereby prohibited from participating in the
query flattening optimization. See
[forum:/forumpost/1d571c02963355ed|forum thread 1d571c02963].
FossilOrigin-Name: 66f29c403d28630bfaea9124bd63ee4a047b1fe4a7e27dc5d10d67d1601b15e0
the cost estimate for constructing an automatic index on an ephemeral table,
in order to resolve the performance problem described by
[forum:/forumpost/1d571c0296|forum post 1d571c0296].
FossilOrigin-Name: bf1aae7a8c7f2c74681aa29baa35259d10ce6a1737d2607def6bf27fed592131
ON CONFLICT clause is accepted and ignored on table CHECK constraints but
raises an error on column CHECK constraints. We want to continue supporting
this harmless quirk to avoid breaking legacy applications and databases that
accidentally use it.
FossilOrigin-Name: 92b6a9cd0fb027fe675b3913aa07c75445bba0cfac9530d08d7e48f7869c04cc
iColumn field is set correctly, as otherwise the "IS NULL" operator might
be incorrectly optimized. Fix for the problem described by
[forum:/forumpost/d010a26798915b53|forum post d010a26798915b53].
FossilOrigin-Name: 0819a1869a39d54a405259ea323365506a182962a02affdef16a03446005da64
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
app-defined functions and similar to see if they need to exit early due to
an sqlite3_interrupt() call.
FossilOrigin-Name: d030f341369b7f32789cbcf3d0ad9a2ac5cad99a56dac7dfe68b7f06dc339b17
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
which is included in the CLI by default) ensure that fopen() is not invoked
using a NULL filename. Fix for the issue reported by
[forum:/forumpost/d1c96a9032e564f8|forum post d1c96a9032e564f8].
FossilOrigin-Name: d32757ddf5d311b6f62545c861fd606244e03f02cb2e317c1131ee6b80c2299c
stored in indexes are byte-for-byte identical to the values in the table, and
not just equivalent according to the collating sequence.
dbsqlfuzz 686e2e205e0c0594d3fb524bea0c25e621d1a870.
FossilOrigin-Name: 9302e4bfdce5905576b8f0af7d6b3a864e1dcd58ed89bb303010a1c4f826e915
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
