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.