table can be NULL even if that column as a NOT NULL constraint.
Fix for ticket [6f2222d550f5b0ee7ed].
FossilOrigin-Name: 6f6fcbe4736b9468a495c684d5eebc8bfe5c566a
argument of an ALTER TABLE ADD COLUMN and to be understand on the RHS of
range constraints interpreted by STAT3/4. This involves a rewrite of the
implementation of the CAST operator.
FossilOrigin-Name: 91d8a8d0b792ea5c4fe68fd9caaf3345eddea486
The error message is not quite as good, but as this error has apparently
not previously occurred in over 8 years of heavy use, that is not seen as
a serious problem.
FossilOrigin-Name: 0ad1ed8ef0b5fb5d8db44479373b2b93d8fcfd66
faster queries in some cases, for example when the RHS of the IN operator
changes for each row of a large table scan.
FossilOrigin-Name: 436e884215e2b33ca3fbb555362237b12827c07a
comments explaining the IN-operator code, though it is not clear that the
comments are correct even yet - more work to be done.
FossilOrigin-Name: c11e55fabbc718cb324ecd3540453c25db98f50c
turns out to be helpful. If the list is of length 1 or 2, the OR expression
is very slightly faster, but the ephemeral table approach is clearly better for
all list lengths greater than 2. Better to keep the code simple.
FossilOrigin-Name: e13175d3579e1045165bab091b3b28951d691704
since it should not make any difference in the output but dues consume extra
memory and CPU time.
FossilOrigin-Name: f4cb53651b1e352fae7378878b830a902bcd9248
hex literals. Casting and coercing string literals into numeric values does
not understand hexadecimal integers. This preserves backwards compatibility.
Also: Throw an error on any hex literal that is too big to fit into 64 bits.
FossilOrigin-Name: 6c6f0de59bf96b79c8ace8c9bfe48c7a6a306a50
incorrect, as demonstrated by the in4-5.1 test case in this check-in.
The "COLLATE binary" that was being added to the RHS of IN was overriding
the implicit collating sequence of the LHS. This change defines the EP_Generic
expression node property that blocks all affinity or collating sequence
information in the expression subtree and adds that property to the expression
taken from RHS of the IN operator.
FossilOrigin-Name: 2ea4a9f75f46eaa928ba17e9e91bc0432750d46d
on the RHS on the first iteration, then remember the result. There has been
logic to do this for year, but it didn't work right and ended up repeating
the NULL test on every iteration. This inefficiency was found using the
VDBE coverage testing tools.
FossilOrigin-Name: 915f6f1c7aab54583729e60bdc1565f25ecc6f74
generates output directly in the registers that INSERT INTO will be using,
in many cases, and OP_SCopy operations can thus be avoided.
FossilOrigin-Name: aa2d8b0e8154dd2f5e2c837dc11ab362b083495b
unordered because the NGQP will use those ephemeral tables to help order the
output. This is not an issue for standard SQLite since ephemeral tables
there are always ordered, regardless of the hint. It only affects systems
that substitute an alternative storage engine.
FossilOrigin-Name: f2504089df0bf4011864e67825b37f6aa3d03458
