Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.11, 11.4, 11.8, 12.3, 13.0, 13.1, 13.2
Description
Similar to MDEV-41475, however the patch does not overlap, so adding it as a separate bug.
--source include/have_partition.inc
|
 |
CREATE TABLE t1 (d DATE) PARTITION BY RANGE (YEAR(d)) (PARTITION p0 VALUES LESS THAN (2000), PARTITION p1 VALUES LESS THAN MAXVALUE); |
INSERT INTO t1 VALUES ('2000-01-00'); |
--let $c= query_get_value(SELECT COUNT(*) AS c FROM t1 WHERE d < '2000-01-01', c, 1)
|
if ($c != 1) |
{
|
--die The row 2000-01-00 is not found by d < '2000-01-01' on a table partitioned by YEAR(d) |
}
|
DROP TABLE t1; |
Leads to:
|
CS 13.1.0 da18481158c81ca94689702073c3e04aad85a6a3 (Debug, Clang 22.1.8-20260622) Build 18/08/2026 |
mysqltest: At line 8: The row 2000-01-00 is not found by d < '2000-01-01' on a table partitioned by YEAR(d)
|
Partitioning changes the query result. Without partitioning, the query finds the row. A zero month, as in '2000-00-15', is missed as well. Optimized builds give the same result.
From the code it seems that Item_func_year::val_int_endpoint() in sql/item_timefunc.cc turns d < '2000-01-01' into YEAR(d) < 2000. A DATE value with a zero day or a zero month in the year 2000 is smaller than '2000-01-01', but its YEAR() is 2000.
Attachments
Issue Links
- relates to
-
MDEV-37441 Optimizer is scanning the first partition for unknown reason
-
- Closed
-
-
MDEV-41475 Partitioning by TO_SECONDS(), TO_DAYS() or UNIX_TIMESTAMP() changes the query result: a row with fractional seconds is not found
-
- Open
-