Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
5.5(EOL), 10.0(EOL), 10.1(EOL)
Description
This bug is similar to http://bugs.mysql.com/bug.php?id=5134
Note, the patch for MySQL bug#5134 fixed only a particular case of the problem when the BINARY keyword is used. The problem is in fact more general.
This script:
SET NAMES latin1;
|
DROP TABLE IF EXISTS t1;
|
CREATE TABLE t1 (a CHAR(10));
|
INSERT INTO t1 VALUES ('a'),('A');
|
SELECT * FROM t1 WHERE a = 'a' COLLATE latin1_bin;
|
correctly returns one row:
+------+
|
| a |
|
+------+
|
| a |
|
+------+
|
Now if I add an extra part into the condition:
SELECT * FROM t1 WHERE a='a' AND a='a' COLLATE latin1_bin;
|
it returns two rows:
+------+
|
| a |
|
+------+
|
| a |
|
| A |
|
+------+
|
The expected result is to return one row in both cases.
The problem happens because "AND a='a' COLLATE latin1_bin" gets erroneously replaced to "AND 'a'='a' COLLATE latin1_bin" which is further evaluates to TRUE and gets removed from the WHERE condition. So, the query gets rewritten to:
SELECT * FROM t1 WHERE a='a';
|
The method which actually replaces the field to the constant is Item_field::equal_fields_propagator() in item.cc.
This condition is not strict enough:
if (!item || !has_compatible_context(item))
|
item= this;
|
It should also take into account the collations of the two operations that the field "a" appears in.
Attachments
Issue Links
- blocks
-
MDEV-8728 Fix a number of problems in equal field and equal expression propagation
- Closed