Bug#28878: InnoDB tables with UTF8 character set and indexes cause wrong result for DML
When making key reference buffers over CHAR fields whitespace (0x20) must be used to fill in the remaining space in the field's buffer. This is what Field_string::store() does. Fixed Field_string::get_key_image() to do the same.
This is for bug #29446 "Specifying a myisam_sort_buffer > 4GB on 64 bit machines not possible". Support for myisam_sort_buffer_size > 4 GB on 64-bit Windows will be looked at later in 5.2.
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.
clean up SHOW GRANTS so it will show host-names with case as entered.
make REVOKE and friends case-sensitive to make things more intuitive.
Patch by Martin Friebe.
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.
