result of the test case for FORCE INDEX on ORDER BY
order_by.test:
test case for FORCE INDEX on ORDER BY
sql_select.cc:
Changing behaviour that MySQL server takes FORCE INDEX clause into account when optimising ORDER BY clause
BINARY(N) and VARBIBARY(N)
2. More 4.0 compatibility and more BINARY keyword consistency:
2a. CREATE TABLE a (a CHAR(N) BINARY)
is now synonym for
CREATE TABLE a (a CHAR(N) COLLATE xxxx_bin)
2b. SELECT BINARY x
is still synonin for
SELECT x COLLATE xxxxx_bin.
Don't read character set files if we are using only the default charset. In most cases the user will not anymore get a warning about missing character set files
Compare strings with space extend instead of space strip. Now the following comparisons holds: "a" == "a " and "a\t" < "a". (Bug #3152).
Note: Because of the above fix, one has to do a REPAIR on any table that has an ascii character < 32 last in a CHAR/VARCHAR/TEXT columns.
Item_func_from_days::get_date didn't change 'hr', 'min' and some
other fields of incoming ltime, so they got random values.
bzeroing of the ltime added
Problem is that Item::save_in_field modifies str_value member
before it calls val_str but Item_copy_string::val_str just returns
this str_value as the result.
I added local String variable to the Item::save_in_field
Procedure names were unintentionally case-sensitive when read from the database
(but case-insensitive when fetched from the cache).
Note that the DB-part of qualified names is still case-sensitive (for consistency
with other usage in mysql).
A test case for the bug that allowed table names to be used in ORDER BY columns (But #3064)
union.test:
A test case for the bug that allowed table names to be used in ORDER BY columns (But #3064)
sql_union.cc:
A fix for a bug that allowed table names to be used in ORDER BY columns (But #3064)
this is better in this case:
- imagine user1 has created a temp table
- imagine user2 does FLUSH TABLES WITH READ LOCK, then takes a backup,
then RESET MASTER then UNLOCK TABLES, like mysqldump --first-slave
- then in the binlog you will finally have the DROP TEMPORARY TABLE,
but not the CREATE TEMPORARY TABLE, so when you later restore with
mysqlbinlog|mysql, mysql will complain that table does not exist.
Replication was already protected of this (it processes DROP TEMPORARY
TABLE as if there was a IF EXISTS), now I add it directly to the query
for mysqlbinlog|mysql to work.
