Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
11.8.1, 10.5, 10.6, 10.11, 11.4
Description
I run the following statements, in which an empty query result should be reuturned.
DROP TABLE IF EXISTS t1; |
CREATE TABLE t1 (c1 BLOB NOT NULL); |
INSERT INTO t1 (c1) VALUES (1); |
SELECT c1 FROM t1 WHERE c1 NOT LIKE c1; -- actual:{1}, expected:{} |
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
This bug happens because, during optimize_cond, we incorrectly remove the NOT LIKE condition (for the BLOB case) when removing equality conditions. Other types, like int, are handled correctly.
The target version is 10.11 and higher (as in the pull request) as this is not a security issue .
For the release notes:
queries that use the construct col1 NOT LIKE col1 (with reference to the same column on both sides) where col1 is a char/varchar/etc column that uses BINARY collation could produce wrong result.
Thanks! I repeated on 10.5-11.8:
MariaDB [test]> explain extended SELECT c1 FROM t1 WHERE c1 NOT LIKE c1;+------+-------------+-------+------+---------------+------+---------+------+------+----------+-------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra |+------+-------------+-------+------+---------------+------+---------+------+------+----------+-------+| 1 | SIMPLE | t1 | ALL | NULL | NULL | NULL | NULL | 1 | 100.00 | |+------+-------------+-------+------+---------------+------+---------+------+------+----------+-------+1 row in set, 1 warning (0.001 sec)Note (Code 1003): select `test`.`t1`.`c1` AS `c1` from `test`.`t1` where 1MariaDB [test]> SELECT c1 FROM t1 WHERE c1 NOT LIKE c1;+----+| c1 |+----+| 1 |+----+1 row in set (0.000 sec)