Disable const propagation for Item_hex_string.
This must be done because Item_hex_string->val_int() is not
the same as (Item_hex_string->val_str() in BINARY column)->val_int().
We cannot simply disable the replacement in a particular context (
e.g. <bin_col> = <int_col> AND <bin_col> = <hex_string>) since
Items don't know the context they are in and there are functions like
IF (<hex_string>, 'yes', 'no').
Note that this will disable some valid cases as well
(e.g. : <bin_col> = <hex_string> AND <bin_col2> = <bin_col>) but
there's no way to distinguish the valid cases without having the
Item's parent say something like : Item->set_context(Item::STRING_RESULT)
and have all the Items that contain other Items do that consistently.
optimizer does not honor IGNORE INDEX
- Allow an index to be used for sorting the table
instead of filesort only if it is not disabled by
IGNORE INDEX.
table in a join
The optimizer removes redundant columns in ORDER BY. It is considering
redundant every reference to const table column, e.g b in :
create table t1 (a int, b int, primary key(a));
select 1 from t1 order by b where a = 1
But it must not remove references to const table columns if the
const table is an outer table because there still can be 2 values :
the const value and NULL. e.g.:
create table t1 (a int, b int, primary key(a));
select t2.b c from t1 left join t1 t2 on (t1.a = t2.a and t2.a = 5)
order by c;
Treat queries with no FROM and aggregate functions as normal queries,
so the aggregate function get correctly calculated as if there is 1 row.
This means that they will be considered to have one row, so COUNT(*) will return
1 instead of 0. Other aggregates will behave in compatible manner.
time_format() claimed %H and %k would return at most two digits
(hours 0-23), but this coincided neither with actual behaviour
nor with docs. this is not visible in simple queries; forcing
a temp-table is probably the easiest way to see this. adjusted
the return-length appropriately; the alternative would be to
adjust the docs to say that behaviour for > 99 hours is undefined.
---
Bug#19844: time_format in Union truncates values
time_format() claimed %H and %k would return at most two digits
(hours 0-23), but this coincided neither with actual behaviour
nor with docs. this is not visible in simple queries; forcing
a temp-table is probably the easiest way to see this. adjusted
the return-length appropriately; the alternative would be to
adjust the docs to say that behaviour for > 99 hours is undefined.
SIGINT is handled in funny ways on windows, which could lead to problems when
Control-C was pressed in the client during a long-running query. Now Control-C
during a query aborts that query (by sending KILL to the server on a second
connexion), while Control-C outside of a running query terminates the client.
Problem described in this bug report affects MyISAM tables only.
Running mysqld --flush instructs mysqld to sync all changes to disk
after each SQL statement. It worked well for INSERT and DELETE
statements, but it did sync for UPDATE only in case if there was
index change (change of colum that has an index). If no updated column
has an index, data wasn't synced to disk.
This fix makes UPDATE statement to sync data to disk even if there is
no index change (that is only data change) and mysqld is run with
--flush option.
