Merge polly.(none):/home/kaa/src/opt/bug32202/my51-bug26215

into  polly.(none):/home/kaa/src/opt/mysql-5.1-opt

mysql-test/r/group_by.result

@@ -1064,6 +1064,71 @@ select t1.f1,t.* from t1, t1 t group by 1;
 ERROR 42000: 'test.t.f1' isn't in GROUP BY
 drop table t1;
 SET SQL_MODE = '';
+CREATE TABLE t1(
+id INT AUTO_INCREMENT PRIMARY KEY, 
+c1 INT NOT NULL, 
+c2 INT NOT NULL,
+UNIQUE KEY (c2,c1));
+INSERT INTO t1(c1,c2) VALUES (5,1), (4,1), (3,5), (2,3), (1,3);
+SELECT * FROM t1 ORDER BY c1;
+id	c1	c2
+5	1	3
+4	2	3
+3	3	5
+2	4	1
+1	5	1
+SELECT * FROM t1 GROUP BY id ORDER BY c1;
+id	c1	c2
+5	1	3
+4	2	3
+3	3	5
+2	4	1
+1	5	1
+SELECT * FROM t1 GROUP BY id ORDER BY id DESC;
+id	c1	c2
+5	1	3
+4	2	3
+3	3	5
+2	4	1
+1	5	1
+SELECT * FROM t1 GROUP BY c2 ,c1, id ORDER BY c2, c1;
+id	c1	c2
+2	4	1
+1	5	1
+5	1	3
+4	2	3
+3	3	5
+SELECT * FROM t1 GROUP BY c2, c1, id ORDER BY c2 DESC, c1;
+id	c1	c2
+3	3	5
+5	1	3
+4	2	3
+2	4	1
+1	5	1
+SELECT * FROM t1 GROUP BY c2, c1, id ORDER BY c2 DESC, c1 DESC;
+id	c1	c2
+3	3	5
+4	2	3
+5	1	3
+1	5	1
+2	4	1
+SELECT * FROM t1 GROUP BY c2  ORDER BY c2, c1;
+id	c1	c2
+1	5	1
+4	2	3
+3	3	5
+SELECT * FROM t1 GROUP BY c2  ORDER BY c2 DESC, c1;
+id	c1	c2
+3	3	5
+4	2	3
+1	5	1
+SELECT * FROM t1 GROUP BY c2  ORDER BY c2 DESC, c1 DESC;
+id	c1	c2
+3	3	5
+4	2	3
+1	5	1
+DROP TABLE t1;
+End of 5.0 tests
 CREATE TABLE t1 (a INT, b INT,
 PRIMARY KEY (a),
 KEY i2(a,b));

mysql-test/t/group_by.test

@@ -790,6 +790,41 @@ drop table t1;
 SET SQL_MODE = '';
 
 #
+
+#
+# Bug #32202: ORDER BY not working with GROUP BY
+#
+
+CREATE TABLE t1(
+  id INT AUTO_INCREMENT PRIMARY KEY, 
+  c1 INT NOT NULL, 
+  c2 INT NOT NULL,
+  UNIQUE KEY (c2,c1));
+
+INSERT INTO t1(c1,c2) VALUES (5,1), (4,1), (3,5), (2,3), (1,3);
+
+# Show that the test cases from the bug report pass
+SELECT * FROM t1 ORDER BY c1;
+SELECT * FROM t1 GROUP BY id ORDER BY c1;
+
+# Show that DESC is handled correctly
+SELECT * FROM t1 GROUP BY id ORDER BY id DESC;
+
+# Show that results are correctly ordered when ORDER BY fields
+# are a subset of GROUP BY ones
+SELECT * FROM t1 GROUP BY c2 ,c1, id ORDER BY c2, c1;
+SELECT * FROM t1 GROUP BY c2, c1, id ORDER BY c2 DESC, c1;
+SELECT * FROM t1 GROUP BY c2, c1, id ORDER BY c2 DESC, c1 DESC;
+
+# Show that results are correctly ordered when GROUP BY fields
+# are a subset of ORDER BY ones
+SELECT * FROM t1 GROUP BY c2  ORDER BY c2, c1;
+SELECT * FROM t1 GROUP BY c2  ORDER BY c2 DESC, c1;
+SELECT * FROM t1 GROUP BY c2  ORDER BY c2 DESC, c1 DESC;
+
+DROP TABLE t1;
+
+--echo End of 5.0 tests
 # Bug #21174: Index degrades sort performance and 
 #             optimizer does not honor IGNORE INDEX.
 #             a.k.a WL3527.

sql/sql_select.cc

@@ -1081,10 +1081,19 @@ JOIN::optimize()
         We have found that grouping can be removed since groups correspond to
         only one row anyway, but we still have to guarantee correct result
         order. The line below effectively rewrites the query from GROUP BY
-        <fields> to ORDER BY <fields>. One exception is if skip_sort_order is
-        set (see above), then we can simply skip GROUP BY.
-      */
-      order= skip_sort_order ? 0 : group_list;
+        <fields> to ORDER BY <fields>. There are two exceptions:
+        - if skip_sort_order is set (see above), then we can simply skip
+          GROUP BY;
+        - we can only rewrite ORDER BY if the ORDER BY fields are 'compatible'
+          with the GROUP BY ones, i.e. either one is a prefix of another.
+          We only check if the ORDER BY is a prefix of GROUP BY. In this case
+          test_if_subpart() copies the ASC/DESC attributes from the original
+          ORDER BY fields.
+          If GROUP BY is a prefix of ORDER BY, then it is safe to leave
+          'order' as is.
+       */
+      if (!order || test_if_subpart(group_list, order))
+          order= skip_sort_order ? 0 : group_list;
       /*
         If we have an IGNORE INDEX FOR GROUP BY(fields) clause, this must be 
         rewritten to IGNORE INDEX FOR ORDER BY(fields).