- 10 Nov, 2007 7 commits
-
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-
gshchepa/uchum@gleb.loc authored
After adding an index the <VARBINARY> IN (SELECT <BINARY> ...) clause returned a wrong result: the VARBINARY value was illegally padded with zero bytes to the length of the BINARY column for the index search. (<VARBINARY>, ...) IN (SELECT <BINARY>, ... ) clauses are affected too.
-
tnurnberg@white.intern.koehntopp.de authored
into mysql.com:/scratch/tnurnberg/31800/50-31800
-
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.
-
tnurnberg@white.intern.koehntopp.de authored
into mysql.com:/misc/mysql/31990/50-31990
-
- 09 Nov, 2007 3 commits
-
-
kaa@polly.(none) 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.
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-
kaa@polly.(none) 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.
-
- 08 Nov, 2007 5 commits
-
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-4.1-opt
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/bug32103/my50-bug26215
-
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.
-
- 07 Nov, 2007 1 commit
-
-
kaa@polly.(none) 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).
-
- 05 Nov, 2007 5 commits
-
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/31758/my50-31758
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/31758/my50-31758
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-
kaa@polly.(none) authored
the length of the remaining input string. This is to fix mysqldump test failure in PB introduced by the patch for bug #26215.
-
- 02 Nov, 2007 2 commits
-
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-
kaa@polly.(none) authored
bug #26215: mysql command line client should not strip comments from SQL statements and bug #11230: Keeping comments when storing stored procedures With the introduction of multiline comments support in the command line client (mysql) in MySQL 4.1, it became impossible to preserve client-side comments within single SQL statements or stored routines. This feature was useful for monitoring tools and maintenance. The patch adds a new option to the command line client ('--enable-comments', '-c') which allows to preserve SQL comments and send them to the server for single SQL statements, and to keep comments in the code for stored procedures / functions / triggers. The patch is a modification of the contributed patch from bug #11230 with the following changes: - code style changes to conform to the coding guidelines - changed is_prefix() to my_strnncoll() to detect the DELIMITER command, since the first one is case-sensitive and not charset-aware - renamed t/comments-51.* to t/mysql_comments.* - removed tests for comments in triggers since 5.0 does not have SHOW CREATE TRIGGER (those tests will be added back in 5.1). The test cases are only for bug #11230. No automated test case for bug #26215 is possible due to the test suite deficiencies (though the cases from the bug report were tested manually).
-
- 01 Nov, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
The HAVING clause is subject to the same rules as the SELECT list about using aggregated and non-aggregated columns. But this was not enforced when processing implicit grouping from using aggregate functions. Fixed by performing the same checks for HAVING as for SELECT.
-
- 30 Oct, 2007 3 commits
-
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B31884-5.0-opt
-
gkodinov/kgeorge@magare.gmz authored
Item_in_subselect's only externally callable method is val_bool(). However the nullability in the wrapper class (Item_in_optimizer) is established by calling the "forbidden" method val_int(). Fixed to use the correct method (val_bool() ) to establish nullability of Item_in_subselect in Item_in_optimizer.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
Item_func_inet_ntoa and Item_func_conv inherit 'maybe_null' flag from an argument, which is wrong. Both can be NULL with notnull arguments, so that's fixed.
-
- 29 Oct, 2007 5 commits
-
-
gluh@mysql.com/eagle.(none) authored
There are two problems with ROUND(X, D) on an exact numeric (DECIMAL, NUMERIC type) field of a table: 1) The implementation of the ROUND function would change the number of decimal places regardless of the value decided upon in fix_length_and_dec. When the number of decimal places is not constant, this would cause an inconsistent state where the number of digits was less than the number of decimal places, which crashes filesort. Fixed by not allowing the ROUND operation to add any more decimal places than was decided in fix_length_and_dec. 2) fix_length_and_dec would allow the number of decimals to be greater than the maximium configured value for constant values of D. This led to the same crash as in (1). Fixed by not allowing the above in fix_length_and_dec.
-
gluh@mysql.com/eagle.(none) authored
The fix is a copy of Martin Friebe's suggestion. added testing for no_appended which will be false if anything, including the empty string is in result
-
gluh@mysql.com/eagle.(none) authored
-
kaa@polly.(none) authored
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-
- 27 Oct, 2007 2 commits
-
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B30715-merged-5.0-opt
-
- 26 Oct, 2007 3 commits
-
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
tnurnberg@white.intern.koehntopp.de authored
into mysql.com:/misc/mysql/31662/50-31662
-
SHOW FIELDS FROM a view with no valid definer was possible (since fix for Bug#26817), but gave NULL as a field-type. This led to mysqldump-ing of such views being successful, but loading such a dump with the client failing. Patch allows SHOW FIELDS to give data-type of field in underlying table.
-
- 25 Oct, 2007 2 commits
-
-
kaa@polly.(none) authored
doesn't recognize it This is a 5.0 version of the patch, it will be null-merged to 5.1 Problem: 'log' and 'log_slow_queries' were "fixed" variables, i.e. they showed up in SHOW VARIABLES, but could not be used in expressions like "select @@log". Also, using them in the SET statement produced an incorrect "unknown system variable" error. Solution: Make 'log' and 'log_slow_queries' read-only dynamic variables to make them available for use in expressions, and produce a correct error about the variable being read-only when used in the SET statement.
-
gshchepa/uchum@gleb.loc authored
all space column names. The parser has been modified to check VIEW column names with the check_column_name function and to report an error on empty and all space column names (same as for TABLE column names).
-
- 24 Oct, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/work/B30715-merged-5.0-opt
-