Bug #120518 Wrong result for SOME quantified comparison with ELT() returning NULL and PRIMARY KEY optimization
Submitted: 21 May 14:29 Modified: 25 May 19:27
Reporter: ss w Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Optimizer Severity:S3 (Non-critical)
Version:8.0.43 OS:Any
Assigned to: CPU Architecture:Any

[21 May 14:29] ss w
Description:
A query involving a SOME quantified comparison may evaluate inconsistently between WHERE filtering and direct SELECT expression evaluation when the left-hand side is an ELT() expression returning NULL and the subquery reads from a PRIMARY KEY column.

In this case, ELT() returns NULL because its index argument is negative. Therefore, the quantified comparison should evaluate to UNKNOWN, and the outer IS NOT UNKNOWN test should evaluate to FALSE. However, the WHERE query and the direct SELECT expression evaluation produce inconsistent results.

Removing the PRIMARY KEY constraint makes the inconsistency disappear, suggesting that the issue is related to an index-based optimization path for SOME/ANY quantified comparisons combined with NULL semantics handling.

How to repeat:
CREATE TABLE t1135 (c1 DECIMAL(20,0) PRIMARY KEY);
INSERT IGNORE INTO t1135 (c1) VALUES (-64);
SELECT t1135.c1 FROM t1135 WHERE (ELT(-64, -64, 16, -64, t1135.c1) >= SOME (SELECT t1135.c1 FROM t1135) IS NOT UNKNOWN);
-- return 1 rows
SELECT SUM(count) FROM (SELECT ((ELT(-64, -64, 16, -64, t1135.c1) >= SOME (SELECT t1135.c1 FROM t1135)) IS NOT UNKNOWN) IS TRUE AS count FROM t1135) AS ta_norec;
-- return 0
[25 May 19:27] Roy Lyseng
Thank you for the bug report.
Verified as described for the 8.0 release.
For 8.4 and 9.7, this seems fixed.