1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-29 05:21:33 +03:00

MDEV-27382: OFFSET is ignored when combined with DISTINCT

A query in form

  SELECT DISTINCT expr_that_is_inferred_to_be_const LIMIT 0 OFFSET n

produces one row when it should produce none. The issue was in
JOIN_TAB::remove_duplicates() in the piece of logic that tried to
avoid duplicate removal for such cases but didn't account for possible
"LIMIT 0".

Fixed by making Select_limit_counters::set_limit() change OFFSET to 0
when LIMIT is 0.
This commit is contained in:
Sergei Petrunia
2022-01-13 15:53:44 +03:00
parent be8113861c
commit 7259b299a5
3 changed files with 76 additions and 0 deletions

View File

@ -818,3 +818,41 @@ UNION
drop table t1;
--echo End of 5.5 tests
--echo #
--echo # MDEV-27382: OFFSET is ignored when it is combined with the DISTINCT, IN() and JOIN
--echo #
CREATE TABLE t1 (
id int(7) NOT NULL AUTO_INCREMENT,
name varchar(50) DEFAULT NULL,
primary key (id)
);
INSERT INTO t1 VALUES (1, 'Reed'), (10, 'no-child');
CREATE TABLE t2 (
id int(11) NOT NULL AUTO_INCREMENT,
parent_id int(7) NOT NULL,
name varchar(100) DEFAULT NULL,
primary key (id),
key(parent_id)
);
INSERT INTO t2 VALUES (1, 1,'John'), (2, 2,'no-parent');
SELECT DISTINCT p.id
FROM t1 p LEFT JOIN t2 c ON p.id = c.parent_id
WHERE p.id=1
LIMIT 0;
SELECT DISTINCT p.id
FROM t1 p LEFT JOIN t2 c ON p.id = c.parent_id
WHERE p.id=1
LIMIT 0 offset 5;
--echo # Test the second part of the fix: just check that "LIMIT 0 OFFSET n" is
--echo # handled in the same way as "LIMIT 0"
explain select * from t1 limit 0;
explain select * from t1 limit 0 offset 10;
drop table t1, t2;