- 05 Nov, 2009 4 commits
-
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
- 03 Nov, 2009 1 commit
-
-
Kristofer Pettersson authored
-
- 31 Oct, 2009 1 commit
-
-
Alexander Nozdrin authored
-
- 27 Oct, 2009 1 commit
-
-
Alexander Nozdrin authored
-
- 22 Oct, 2009 8 commits
-
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Jonathan Perkin authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
instead of making it experimental.
-
- 20 Oct, 2009 14 commits
-
-
Alexander Nozdrin authored
-
Satya B authored
Remove the extra line which try to use the name INNOBASE again. The IF ELSE loop above declares the library name based on the version of mysql
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Satya B authored
-
Kristofer Pettersson authored
-
Satya B authored
-
Satya B authored
-
Satya B authored
-
Kristofer Pettersson authored
-
Satya B authored
grants are reapplied. After renaming a user and trying to re-apply grants results in additional grants. This is because we use username as part of the key for GRANT_TABLE structure. When the user is renamed, we only change the username stored and the hash key still contains the old user name and this results in the extra privileges Fixed by rebuilding the hash key and updating the column_priv_hash structure when the user is renamed mysql-test/r/grant3.result: Bug #41597 - After rename of user, there are additional grants when grants are reapplied. Testcase for BUG#41597 mysql-test/t/grant3.test: Bug #41597 - After rename of user, there are additional grants when grants are reapplied. Testcase for BUG#41597 sql/sql_acl.cc: Bug #41597 - After rename of user, there are additional grants when grants are reapplied. Fixed handle_grant_struct() to update the hash key when the user is renamed. Added to set_user_details() method to GRANT_NAME class
-
Sergey Vojtovich authored
-
Sergey Vojtovich authored
-
unknown authored
There are some problems about help text: - It is stated that "auto" is the default twice. It need be stated only once. - It is stated that --base64-output is short for --base64-output=always. But that sounds like the default is "always", not "auto". Make the help text clear as following: Determine when the output statements should be base64-encoded BINLOG statements: 'never' disables it and works only for binlogs without row-based events; 'auto' prints base64 only when necessary (i.e., for row-based events and format description events); 'always' prints base64 whenever possible. 'always' is for debugging only and should not be used in a production system. If this argument is not given, the default is 'auto'; if it is given with no argument, 'always' is used.
-
- 19 Oct, 2009 11 commits
-
-
Alexander Nozdrin authored
-
Bjorn Munch authored
Knowledge of no SSL support is not used Skip tests the same way e.g. innodb tests are Does not refer to have_ssl_communication.inc, will add this when merging to 6.0-codebase
-
Bjorn Munch authored
-
Alexander Nozdrin authored
-
Alexander Barkov authored
Problem: the "caseinfo" member of CHARSET_INFO structure was not initialized for user-defined Unicode collations, which made the server crash. Fix: initializing caseinfo properly.
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Bjorn Munch authored
-
Alexander Nozdrin authored
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
-