The problem is that currently there is no way to test the behavior
of the mysql_change_user() function using the mysqltest suite because
there is no internal command for it.
The solution is to introduce a change_user command that can be used
to test aspects of the MySQL client function mysql_change_user().
Before this patch, failures to write to the log tables (mysql.slow_log
and mysql.general_log) were improperly printed (the time was printed twice),
or not printed at all.
With this patch, failures to write to the log tables is reported in the
error log, for all cases of failures.
"DECLARE CURSOR FOR SHOW ..." is a syntax that currently appears to work,
but is untested for some SHOW commands and does not work for other SHOW
commands.
Since this is an un-intended feature that leaked as a result of a coding bug
(in the parser grammar), the correct fix is to fix the grammar to not accept
this construct.
In other words, "DECLARE CURSOR FOR SHOW <other commands that don't work>"
is not considered a bug, and we will not implement other features to make all
the SHOW commands usable inside a cursor just because someone exploited a bug.
when used in a VIEW.
The problem was that wrong function (create_tmp_from_item())
was used to create a temporary field for Item_func_sp.
The fix is to use create_tmp_from_field().
This actually, fix for the patch for bug-27354. The problem with
the patch was that Item_func_sp::used_tables() was updated, but
Item_func_sp::const_item() was not. So, for Item_func_sp, we had
the following inconsistency:
- used_tables() returned RAND_TABLE, which means that the item
can produce "random" results;
- but const_item() returned TRUE, which means that the item is
a constant one.
The fix is to change Item_func_sp::const_item() behaviour: it must
return TRUE (an item is a constant one) only if a stored function
is deterministic and each of its arguments (if any) is a constant
item.
When CREATE TEMPORARY TABLE .. SELECT is invoked from a stored function
which in turn is called from CREATE TABLE SELECT causes a memory leak
because the inner create temporary table overrides the outter extra_lock
reference when locking the table.
The solution is to simply not overrride the extra_lock by only using the
extra_lock for a non-temporary table lock.
insert_id after succ. mysql_change_user() call.
See also WL 4066.
This bug reveals two problems:
- the problem on the client side which was described originally;
- the problem in protocol / the server side: connection context
on client and server should be like after mysql_real_connect()
and be consistent. The server however just resets character
set variables to the global defaults.
The fix seems to be as follows:
- extend the protocol so that the client be able to send
character set information in COM_CHANGE_USER command;
- change the server so that it understands client character set
in the command;
- change the client:
- reset character set to the default value (which has been
read from the configuration);
- send character set in COM_CHANGE_USER command.
added get_field_default_value() function which obtains default value from the field
(used in store_create_info() & get_schema_column_record() functions)
The parser uses ulonglong to store the LIMIT number. This number
then is stored into a variable of type ha_rows. ha_rows is either
4 or 8 byte depending on the BIG_TABLES define from config.h
So an overflow may occur (and LIMIT becomes zero) while storing an
ulonglong value in ha_rows.
Fixed by :
1. Using the maximum possible value for ha_rows on overflow
2. Defining BIG_TABLES for the windows builds (to match the others)
The optimizer sets index traversal in reverse order only if there are
used key parts that are not compared to a constant.
However using the primary key as an ORDER BY suffix rendered the check
incomplete : going in reverse order must still be used even if
all the parts of the secondary key are compared to a constant.
Fixed by relaxing the check and set reverse traversal even when all
the secondary index keyparts are compared to a const.
Also account for the case when all the primary keys are compared to a
constant.
- The bug was caused by COUNT(DISTINCT ...) code using Unique object in
a way that assumed that BIT(N) column occupies a contiguous space in
temp_table->record[0] buffer.
- The fix is to make COUNT(DISTINCT ...) code instruct create_tmp_table to
create temporary table with column of type BIGINT, not BIT(N).
- Introduced val_int_endpoint() function which converts between func
argument intervals and func value intervals for monotonic functions.
- Made partition interval analyzer use part_expr->val_int_endpoint()
to check if the edge values should be included.
Declaring an all space column name in the SELECT FROM DUAL or in a view
leads to misleading warning message:
"Leading spaces are removed from name ' '".
The Item::set_name method has been modified to raise warnings like
"Name ' ' has become ''" in case of the truncation of an all
space identifier to an empty string identifier instead of the
"Leading spaces are removed from name ' '" warning message.
UPGRADE)
Bug 17565 (RENAME DATABASE destroys events)
Bug#28360 (RENAME DATABASE destroys routines)
Removed the
RENAME DATABASE db1 TO db2
statement.
Implemented the
ALTER DATABASE db UPGRADE DATA DIRECTORY NAME
statement, which has the same function.
