]> git.ipfire.org Git - thirdparty/sqlite.git/commit
The "x IN (?)" optimization in check-ins [2ff3b25f40] and [e68b427afb] is
authordrh <drh@noemail.net>
Thu, 20 Mar 2014 17:03:30 +0000 (17:03 +0000)
committerdrh <drh@noemail.net>
Thu, 20 Mar 2014 17:03:30 +0000 (17:03 +0000)
commitfbb24d1092c1c09a9493d382589176c1ba54bd52
treed736a53d950951bd73f29d750efd0c6e078f8f7f
parent4ef7efad5eccd9acc32c3ecce05026914beaa903
The "x IN (?)" optimization in check-ins [2ff3b25f40] and [e68b427afb] is
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
manifest
manifest.uuid
src/expr.c
src/parse.y
src/sqliteInt.h
test/in4.test