- 19 Oct, 2009 7 commits
-
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
- 16 Oct, 2009 13 commits
-
-
Timothy Smith authored
-
Timothy Smith authored
-
Timothy Smith authored
use function prototypes from header in conjunction with K&R-style function definitions. The symptom is a type mismatch between int and wchar_t.
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-
Joerg Bruehe authored
Use "#ifdef", not plain "#if".
-
Satya B authored
also merged missing Innodb plugin revisions r5636,r5635 manually
-
Joerg Bruehe authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 15 Oct, 2009 9 commits
-
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-
Alexander Nozdrin authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Alexey Kopytov authored
-
Sergey Vojtovich authored
-
- 14 Oct, 2009 11 commits
-
-
Jorgen Loland authored
-
Jorgen Loland authored
Temporary tables may set join->group to 0 even though there is grouping. Also need to test if sum_func_count>0 when JOIN::exec() decides whether to present results in a grouped manner. sql/sql_select.cc: Temporary tables may set join->group to 0 even though there is grouping. Also need to test if sum_func_count>0 when JOIN::exec() decides whether to present results in a grouped manner.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
He Zhenxing authored
-
Alexander Nozdrin authored
-
Jorgen Loland authored
columns without where/group Simple SELECT with implicit grouping used to return many rows if the query was ordered by the aggregated column in the SELECT list. This was incorrect because queries with implicit grouping should only return a single record. The problem was that when JOIN:exec() decided if execution needed to handle grouping, it was assumed that sum_func_count==0 meant that there were no aggregate functions in the query. This assumption was not correct in JOIN::exec() because the aggregate functions might have been optimized away during JOIN::optimize(). The reason why queries without ordering behaved correctly was that sum_func_count is only recalculated if the optimizer chooses to use temporary tables (which it does in the ordered case). Hence, non-ordered queries were correctly treated as grouped. The fix for this bug was to remove the assumption that sum_func_count==0 means that there is no need for grouping. This was done by introducing variable "bool implicit_grouping" in the JOIN object. mysql-test/r/func_group.result: Add test for BUG#47280 mysql-test/t/func_group.test: Add test for BUG#47280 sql/opt_sum.cc: Improve comment for opt_sum_query() sql/sql_class.h: Add comment for variables in TMP_TABLE_PARAM sql/sql_select.cc: Introduce and use variable implicit_grouping instead of (!group_list && sum_func_count) in places that need to test if grouping is required. Also added comments for: optimization of aggregate fields for implicitly grouped queries (JOIN::optimize) and choice of end_select method (JOIN::execute) sql/sql_select.h: Add variable implicit_grouping, which will be TRUE for queries that contain aggregate functions but no GROUP BY clause. Also added comment to sort_and_group variable.
-