Fix for bug #34928: Confusion by having Primary Key and Index

The bug is a regression introduced in 5.1 by the patch for bug28404.

Under some circumstances test_if_skip_sort_order() could leave some
data structures in an inconsistent state so that some parts of code
could assume the selected execution strategy for GROUP BY/DISTINCT as
a loose index scan (e.g. JOIN_TAB::is_using_loose_index_scan()), while
the actual strategy chosen was an ordered index scan, which led to
wrong data being returned.

Fixed test_if_skip_sort_order() so that when changing the type for a
join table, select->quick is reset not only for EXPLAIN, but for the 
actual join execution as well, to not confuse code that depends on its
value to determine the chosen GROUP BY/DISTINCT strategy.


mysql-test/r/distinct.result:
  Added a test case for bug #34928.
mysql-test/t/distinct.test:
  Added a test case for bug #34928.
sql/sql_select.cc:
  When changing the table's join type to JT_NEXT in 
  test_if_skip_sort_order(), also reset select->quick because other
  code may depend on its value to determine the GROUP BY/DISTINCT
  execution strategy.

1 files changed, 23 insertions, 0 deletions

diff --git a/mysql-test/t/distinct.test b/mysql-test/t/distinct.test
index bfdb5f8b9f8..559dde44b81 100644
--- a/mysql-test/t/distinct.test
+++ b/mysql-test/t/distinct.test
@@ -553,3 +553,26 @@ SELECT DISTINCT a, a, b FROM t1;
 DROP TABLE t1;
 
 --echo End of 5.0 tests
+
+#
+# Bug #34928: Confusion by having Primary Key and Index
+#
+CREATE TABLE t1(a INT, b INT, c INT, d INT, e INT,
+                PRIMARY KEY(a,b,c,d,e),
+                KEY(a,b,d,c)
+);
+
+INSERT INTO t1(a, b, c) VALUES (1, 1, 1),
+                               (1, 1, 2),
+                               (1, 1, 3),
+                               (1, 2, 1),
+                               (1, 2, 2),
+                               (1, 2, 3);
+
+EXPLAIN SELECT DISTINCT a, b, d, c FROM t1;
+
+SELECT DISTINCT a, b, d, c FROM t1;
+
+DROP TABLE t1;
+
+--echo End of 5.1 tests