Bug #119341 ALL subquery evaluates incorrectly in SELECT list when comparing against a BIT column

Submitted: 10 Nov 2025 8:24 Modified: 11 Nov 2025 7:55
Reporter: zz z Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Optimizer Severity:S3 (Non-critical)
Version:9.4.0 OS:Any
Assigned to: CPU Architecture:Any

[10 Nov 2025 8:24] zz z
Description:
The boolean evaluation of an ALL subquery is incorrect when it reads data from a BIT column and is placed within a SELECT expression of a derived table. In this case, the logical result of the expression 4 <> ALL (SELECT c1 FROM t29) should always be TRUE, as the integer 4 is not equal to any of the values (b'0' or b'1') in the BIT column. However, during query execution, this expression is incorrectly evaluated to FALSE. This causes the subsequent IS TRUE check to fail and leads to the SUM aggregation returning 0 instead of the expected row count of 4. The bug reveals a flaw in how ALL subqueries that involve the BIT data type are handled within the context of a SELECT list.

How to repeat:
CREATE TABLE t29 (c1 BIT);
INSERT t29 () VALUES (b'0');
INSERT t29 () VALUES (b'1');
INSERT t29 () VALUES (b'1');
INSERT t29 () VALUES (b'1');

SELECT * FROM t29 WHERE (4 <> ALL (SELECT t29.c1 FROM t29));
-- 4 rows
SELECT SUM(count) FROM (SELECT ((4 <> ALL (SELECT t29.c1 FROM t29))) IS TRUE AS count FROM t29) AS ta_norec;
-- 0
[11 Nov 2025 7:55] Roy Lyseng
Verified as described.

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.050 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.