- 28 Nov, 2008 2 commits
-
-
Sergey Glukhov authored
sql/slave.cc: compiler warning fix
-
Sergey Glukhov authored
mysql-test/r/perror-win.result: pushbuild failure fix mysql-test/t/perror-win.test: pushbuild failure fix sql/item_func.cc: pushbuild failure fix
-
- 27 Nov, 2008 20 commits
-
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
-
Horst Hunger authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
The bug is repeatable with latest(1.0.1) InnoDB plugin on Linux, Win, If MySQL is compiled with valgrind there are errors about using of uninitialized variable(orig_table). The fix is to set field->orig_table correct value. mysql-test/r/innodb_mysql.result: test result mysql-test/t/innodb_mysql.test: test case sql/sql_base.cc: set field->orig_table to 'table' value because it may be bogus and it leads to crash on Field_string::type() function.
-
Horst Hunger authored
Reason for the failing test was that "SELECT count(*) from mysql.general_log;" was not always the same number. That was fixed by "...count(*)>4..." as the minimal fulfilled condition. As Bug 35371 was fixed the testcase with "log_output = 'FILE'" was enabled and changed to have always the same result.
-
Sergey Glukhov authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
enable uncacheable flag if we update a view with check option and check option has a subselect, otherwise, the check option can be evaluated after the subselect was freed as independent (See full_local in JOIN::join_free()) mysql-test/r/subselect.result: test result mysql-test/t/subselect.test: test case sql/mysql_priv.h: added UNCACHEABLE_CHECKOPTION flag sql/sql_update.cc: enable uncacheable flag if we update a view with check option and check option has a subselect, otherwise, the check option can be evaluated after the subselect was freed as independent (See full_local in JOIN::join_free())
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
set DATE|DATETIME value to 0 if ALLOW_INVALID_DATES sql_mode is not enabled. sql/field.cc: set DATE|DATETIME value to 0 if ALLOW_INVALID_DATES sql_mode is not enabled. tests/mysql_client_test.c: test case
-
Sergey Glukhov authored
extended perror to enable printing of Win32 system errors extra/perror.c: extended perror to enable printing of Win32 system errors mysql-test/r/perror-win.result: test result mysql-test/t/perror-win.test: test case
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
-
- 26 Nov, 2008 7 commits
-
-
Patrick Crews authored
-
Patrick Crews authored
-
Ingo Struewing authored
-
Matthias Leich authored
(no conflicts)
-
Ingo Struewing authored
-
Horst Hunger authored
-
Tatiana A. Nurnberg authored
We pretended that TIMEDIFF() would always return positive results; this gave strange results in comparisons of the TIMEDIFF(low,hi)<TIME(0) type that rendered a negative result, but still gave false in comparison. We also inadvertantly dropped the sign when converting times to decimal. CAST(time AS DECIMAL) handles signs of the times correctly. TIMEDIFF() marked up as signed. Time/date comparison code switched to signed for clarity. mysql-test/r/func_sapdb.result: show that time-related comparisons work with negative time values now. show that converting time to DECIMAL no longer drops sign. mysql-test/t/func_sapdb.test: show that time-related comparisons work with negative time values now. show that converting time to DECIMAL no longer drops sign. sql/item_cmpfunc.cc: signed returns sql/item_cmpfunc.h: signed now (time/date < > =) sql/item_func.cc: signed now sql/item_timefunc.h: Functions such as TIMEDIFF() return signed results! The file-comments pretended we were doing that all along, anyway... sql/my_decimal.cc: heed sign when converting time to my_decimal; times may actually be negative! Needed for SELECT CAST(time('-73:42:12') AS DECIMAL); sql/mysql_priv.h: using signed for dates and times now
-
- 25 Nov, 2008 11 commits
-
-
Vladislav Vaintroub authored
-
Matthias Leich authored
-
Matthias Leich authored
-
Ingo Struewing authored
symlink.test failed when run in an environment that has mysql-test/var symlinked to elsewhere, e.g. a memory file system. This is the case when running mysql-test-run --mem. In this case the server does not detect that the directory specified with a DATA/INDEX DIRECTORY clause is within its data home directory. This problem was reported as Bug#39277 (Creation of table with data and/or index files in data home directory succeeds). It was decided that it will not be fixed in 5.1. Hence, the current behavior is accepted for 5.1. It will be fixed in 6.0 though. Fixed the test case so that it works in both environments. 1. When no symbolic link is involved, the server notices that the data/index directory is in its data hone directory and rejects the CREATE/ALTER TABLE statement. 2. When the data home directory is symlinked, it does not notice the problem and executes the statement sucessfully. mysql-test/r/symlink.result: Bug#41002 - symlink.test fails on symlinked datadir Updated test result. mysql-test/t/symlink.test: Bug#41002 - symlink.test fails on symlinked datadir Adjusted the test case to the accepted behavior. It needs to accept success and failure of some statements.
-
Matthias Leich authored
-
Matthias Leich authored
-
Matthias Leich authored
-
Matthias Leich authored
-
Ingo Struewing authored
-
Ramil Kalimullin authored
-
Ingo Struewing authored
-