- 10 Nov, 2007 12 commits
-
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.1-opt mysql-test/r/select.result: Auto merged mysql-test/t/select.test: Auto merged sql/sql_select.cc: Auto merged
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.1-opt sql/sql_select.cc: Auto merged
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt sql/sql_select.cc: Auto merged
-
unknown authored
into polly.(none):/home/kaa/src/opt/bug32202/my51-bug26215 mysql-test/r/group_by.result: Manual merge. mysql-test/t/group_by.test: Manual merge. sql/sql_select.cc: Manual merge.
-
unknown authored
into mysql.com:/home/hf/work/31893/my51-31893
-
unknown authored
into mysql.com:/misc/mysql/31800/51-31800 mysql-test/r/select.result: Auto merged mysql-test/t/select.test: Auto merged
-
unknown authored
into mysql.com:/scratch/tnurnberg/31800/50-31800 mysql-test/r/select.result: Auto merged mysql-test/t/select.test: Auto merged
-
unknown authored
into mysql.com:/misc/mysql/31800/51-31800 mysql-test/r/select.result: Auto merged mysql-test/t/select.test: Auto merged sql-common/my_time.c: Auto merged sql/item_cmpfunc.cc: Auto merged
-
unknown authored
BETWEEN was more lenient with regard to what it accepted as a DATE/DATETIME in comparisons than greater-than and less-than were. ChangeSet makes < > comparisons similarly robust with regard to trailing garbage (" GMT-1") and "missing" leading zeros. Now all three comparators behave similarly in that they throw a warning for "junk" at the end of the data, but then proceed anyway if possible. Before < > fell back on a string- (rather than date-) comparison when a warning-condition was raised in the string-to-date conversion. Now the fallback only happens on actual errors, while warning- conditions still result in a warning being to delivered to the client. mysql-test/r/select.result: Show that we compare DATE/DATETIME-like strings as date(time)s now, rather than as bin-strings. Adjust older result as "2005-09-3a" is now correctly seen as "2005-09-3" + trailing garbage, rather than as "2005-09-30". mysql-test/t/select.test: Show that we compare DATE/DATETIME-like strings as date(time)s now, rather than as bin-strings. sql-common/my_time.c: correct/clarify date-related comments, particulary for check_date(). doxygenize comment while at it. sql/item_cmpfunc.cc: get_date_from_str() no longer signals an error when all we had was a warning-condition -- and one we already gave the user a warning for at that. Preamble doxygenized.
-
unknown authored
into mysql.com:/misc/mysql/31990/51-31990
-
unknown authored
into mysql.com:/misc/mysql/31990/50-31990
-
unknown authored
into mysql.com:/misc/mysql/31990/51-31990 mysql-test/r/cast.result: Auto merged mysql-test/t/cast.test: Auto merged sql/item_timefunc.cc: Auto merged sql/item_timefunc.h: Auto merged
-
- 09 Nov, 2007 6 commits
-
-
unknown authored
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. mysql-test/r/group_by.result: Added a test case for bug #32202. mysql-test/t/group_by.test: Added a test case for bug #32202. sql/sql_select.cc: In cases when groups in GROUP BY correspond to only one row and there is ORDER BY, rewrite the query to ORDER BY <group_by_columns> only if the columns in ORDER BY and GROUP BY are compatible, i.e. either one forms a prefix for another.
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.1-opt sql/sql_udf.cc: Auto merged
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.1-opt sql/sql_udf.cc: Auto merged
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt sql/sql_udf.cc: Auto merged
-
unknown authored
into polly.(none):/home/kaa/src/opt/bug32020/my51-bug31445 mysql-test/r/skip_grants.result: Auto merged mysql-test/t/skip_grants.test: Auto merged sql/sql_udf.cc: Auto merged
-
unknown authored
causes out of memory errors The code in mysql_create_function() and mysql_drop_function() assumed that the only reason for UDFs being uninitialized at that point is an out-of-memory error during initialization. However, another possible reason for that is the --skip-grant-tables option in which case UDF initialization is skipped and UDFs are unavailable. The solution is to check whether mysqld is running with --skip-grant-tables and issue a proper error in such a case. mysql-test/r/skip_grants.result: Added a test case for bug #32020. mysql-test/t/skip_grants.test: Added a test case for bug #32020. sql/sql_udf.cc: Issue a proper error when a user tries to CREATE/DROP a UDF on a server running with the --skip-grant-tables option.
-
- 08 Nov, 2007 8 commits
-
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.1-opt mysql-test/r/select.result: Auto merged mysql-test/t/select.test: Auto merged
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.1-opt mysql-test/r/select.result: Auto merged mysql-test/t/select.test: Auto merged
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt mysql-test/r/select.result: Auto merged mysql-test/t/select.test: Auto merged
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-4.1-opt
-
unknown authored
into polly.(none):/home/kaa/src/opt/bug32103/my51-bug26215 mysql-test/r/select.result: Auto merged mysql-test/t/select.test: Auto merged sql/item.h: Auto merged
-
unknown authored
into polly.(none):/home/kaa/src/opt/bug32103/my50-bug26215 mysql-test/t/select.test: Auto merged mysql-test/r/select.result: Manual merge. sql/item.h: Manual merge.
-
unknown authored
HOUR(), MINUTE(), ... returned spurious results when used on a DATE-cast. This happened because DATE-cast object did not overload get_time() method in superclass Item. The default method was inappropriate here and misinterpreted the data. Patch adds missing method; get_time() on DATE-casts now returns SQL-NULL on NULL input, 0 otherwise. This coincides with the way DATE-columns behave. mysql-test/r/cast.result: Show that HOUR(), MINUTE(), ... return sensible values when used on DATE-cast objects, namely NULL for NULL-dates and 0 otherwise. Show that this coincides with how DATE-columns behave. mysql-test/t/cast.test: Show that HOUR(), MINUTE(), ... return sensible values when used on DATE-cast objects, namely NULL for NULL-dates and 0 otherwise. Show that this coincides with how DATE-columns behave. sql/item_timefunc.cc: Add get_time() method to DATE-cast object to overload the method in Item superclass that would return spurious results. Return zero-result; flag NULL if input was NULL. sql/item_timefunc.h: Add get_time() declaration to DATE-cast object.
-
- 07 Nov, 2007 3 commits
-
-
unknown authored
variable in where clause. Problem: the new_item() method of Item_uint used an incorrect constructor. "new Item_uint(name, max_length)" calls Item_uint::Item_uint(const char *str_arg, uint length) which assumes the first argument to be the string representation of the value, not the item's name. This could result in either a server crash or incorrect results depending on usage scenarios. Fixed by using the correct constructor in new_item(): Item_uint::Item_uint(const char *str_arg, longlong i, uint length). mysql-test/r/select.result: Added a test case for bug #32103. mysql-test/t/select.test: Added a test case for bug #32103. sql/item.h: Use the correct constructor for Item_uint in Item_uint::new_item().
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.1-opt sql/opt_range.cc: Auto merged
-
unknown authored
Calculating the estimated number of records for a range scan may take a significant time, and it was impossible for a user to interrupt that process by killing the connection or the query. Fixed by checking the thread's 'killed' status in check_quick_keys() and interrupting the calculation process if it is set to a non-zero value. sql/opt_range.cc: Check the thread's 'killed' status in check_quick_keys() and interrupt the calculation process if it is set to a non-zero value.
-
- 06 Nov, 2007 2 commits
- 05 Nov, 2007 9 commits
-
-
unknown authored
into mysql.com:/home/hf/work/31758/my51-31758
-
unknown authored
into mysql.com:/home/hf/work/31758/my51-31758
-
unknown authored
into mysql.com:/home/hf/work/31758/my50-31758
-
unknown authored
-
unknown authored
into mysql.com:/home/hf/work/31758/my51-31758 mysql-test/t/func_str.test: Auto merged sql/item_strfunc.h: Auto merged mysql-test/r/func_str.result: merging
-
unknown authored
-
unknown authored
into mysql.com:/home/hf/work/31758/my50-31758 mysql-test/t/func_str.test: Auto merged mysql-test/r/func_str.result: merging sql/item_strfunc.h: merging
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.1-opt client/mysql.cc: Auto merged
-
unknown authored
into polly.(none):/home/kaa/src/opt/mysql-5.1-opt client/mysql.cc: Auto merged
-