(and ticket [e39d032577df6942]) as it causes difficult affinity problems
as demonstrated by ticket [dbaf8a6820be1ece] and the original assertion fault
is no longer a factor due to countless other changes of the previous 5 years.
FossilOrigin-Name: 7f5168a76a400fc2e1e40c6950470b1bfb38a0be54fc5518c17c29fdae7d8f1f
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
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
as "x==?" do to collation and affinity issues. The correct converstion should
be to "x==(+? COLLATE binary)". The current check-in fixes this problem and
provides test cases. Ticket [e39d032577df69]
FossilOrigin-Name: 2ff3b25f40fd117c8a2da1d1a3625f6b167b7b16
RHS of the IN into equality tests: "X=?". Add test cases to verify that
statements work correctly on this corner case.
Fix for ticket [e39d032577df6942].
FossilOrigin-Name: e68b427afbc82e201c64474117851aa4c9eb0c92
