- 08 Feb, 2008 12 commits
-
-
kostja@dipika.(none) authored
into dipika.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@dipika.(none) authored
into dipika.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@dipika.(none) authored
into dipika.(none):/opt/local/work/mysql-5.0-runtime
-
kostja@dipika.(none) authored
simply killed.
-
kostja@dipika.(none) authored
into dipika.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@dipika.(none) authored
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
davi@mysql.com/endora.local authored
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
davi@mysql.com/endora.local authored
The unsignedness of large integer user variables was not being properly preserved when feeded to prepared statements. This was happening because the unsigned flags wasn't being updated when converting the user variable is converted to a parameter. The solution is to copy the unsigned flag when converting the user variable to a parameter and take the unsigned flag into account when converting the integer to a string.
-
kostja@dipika.(none) authored
into dipika.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@dipika.(none) authored
table.
-
- 07 Feb, 2008 10 commits
-
-
davi@mysql.com/endora.local authored
On crashes generate a user-friendly resolved and demangled stack trace when libc provides the necessary functions (newer libc on i386, x86_64, powerpc, ia64, alpha and s390). Otherwise print a numeric stack trace as before, relying on resolve_stack_dump utility.
-
kostja@dipika.(none) authored
into dipika.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@dipika.(none) authored
-
malff@lambda.hsd1.co.comcast.net. authored
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/data/msvensson/mysql/mysql-5.1-runtime
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/data/msvensson/mysql/mysql-5.1-runtime
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/data/msvensson/mysql/mysql-5.1-runtime
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/data/msvensson/mysql/mysql-5.0-runtime
-
davi@mysql.com/endora.local authored
The problem is that one can not create a stored routine if sql_mode contains NO_ENGINE_SUBSTITUTION or PAD_CHAR_TO_FULL_LENGTH. Also when a event is created, the mode is silently lost if sql_mode contains one of the aforementioned. This was happening because the table definitions which stored sql_mode values weren't being updated to accept new values of sql_mode. The solution is to update, in a backwards compatible manner, the various table definitions (columns) that store the sql_mode value to take into account the new possible values. One incompatible change is that if a event that is being created can't be stored to the mysql.event table, an error will be raised. The tests case also ensure that new SQL modes will be added to the mysql.proc and mysql.event tables, otherwise the tests will fail.
-
- 06 Feb, 2008 6 commits
-
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
davi@mysql.com/endora.local authored
Changed "SHOW ENGINE ... STATUS" and "SHOW ENGINE ... MUTEX" to require the PROCESS privilege, instead of SUPER. Fixed by Damien Katz
-
-
anozdrin/alik@quad. authored
transfered by CREATE TABLE/SELECT to the new table.
-
davi@mysql.com/endora.local authored
Re-enable the test case for Bug 30331.
-
- 05 Feb, 2008 4 commits
-
-
anozdrin/alik@quad. authored
Bug 34311: main.lock_multi.test fails.
-
mkindahl@dl145h.mysql.com authored
cause sporadic, but benign, errors.
-
anozdrin/alik@quad. authored
-
mkindahl@dl145h.mysql.com authored
-
- 04 Feb, 2008 8 commits
-
-
thek@adventure.(none) authored
Fixed interference between tests: Users were added but not properly removed. This caused later tests to fail.
-
davi@mysql.com/endora.local authored
The problem is that deprecated syntax warnings were not being suppressed when the stored routine is being parsed for the first execution. It's doesn't make sense to print out deprecated syntax warnings when the routine is being executed because this kind of warning only matters when the routine is being created. The solution is to suppress deprecated syntax warnings when parsing the stored routine for loading into the cache (might mean that the routine is being executed for the first time).
-
mkindahl@dl145h.mysql.com authored
-
mkindahl@dl145h.mysql.com authored
into dl145h.mysql.com:/data0/mkindahl/mysql-5.1-rpl-merge
-
mkindahl@dl145h.mysql.com authored
-
mkindahl@dl145h.mysql.com authored
into dl145h.mysql.com:/data0/mkindahl/mysql-5.1-rpl-merge
-
mkindahl@dl145h.mysql.com authored
-
mkindahl@dl145h.mysql.com authored
-