summaryrefslogtreecommitdiff
path: root/sql/sql_select.cc
diff options
context:
space:
mode:
authorkaa@polly.(none) <>2007-11-09 19:12:12 +0300
committerkaa@polly.(none) <>2007-11-09 19:12:12 +0300
commit8c19367881b6ded5e08649d5a3d50f3e2a48ab0d (patch)
tree2a1cd66fe8c6ef1ff3654c761ee4ae2a9f0e46ad /sql/sql_select.cc
parent8efd7ef146a41e5894a720f7c932740a401d1144 (diff)
downloadmariadb-git-8c19367881b6ded5e08649d5a3d50f3e2a48ab0d.tar.gz
Fix for bug #32202: ORDER BY not working with GROUP BY
The bug is a regression introduced by the fix for bug30596. The problem was that in cases when groups in GROUP BY correspond to only one row, and there is ORDER BY, the GROUP BY was removed and the ORDER BY rewritten to ORDER BY <group_by_columns> without checking if the columns in GROUP BY and ORDER BY are compatible. This led to incorrect ordering of the result set as it was sorted using the GROUP BY columns. Additionaly, the code discarded ASC/DESC modifiers from ORDER BY even if its columns were compatible with the GROUP BY ones. This patch fixes the regression by checking if ORDER BY columns form a prefix of the GROUP BY ones, and rewriting ORDER BY only in that case, preserving the ASC/DESC modifiers. That check is sufficient, since the GROUP BY columns contain a unique index.
Diffstat (limited to 'sql/sql_select.cc')
-rw-r--r--sql/sql_select.cc15
1 files changed, 12 insertions, 3 deletions
diff --git a/sql/sql_select.cc b/sql/sql_select.cc
index 3529de1c28a..3c840027ab5 100644
--- a/sql/sql_select.cc
+++ b/sql/sql_select.cc
@@ -1057,10 +1057,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.
+ <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.
*/
- order= skip_sort_order ? 0 : group_list;
+ if (!order || test_if_subpart(group_list, order))
+ order= skip_sort_order ? 0 : group_list;
group_list= 0;
group= 0;
}