The function agg_cmp_type in item_cmpfunc.cc neglected the fact that
the first argument in a BETWEEN/IN predicate could be a field of a view.
As a result in the case when the retrieved table was hidden by a view
over it and the arguments in the BETWEEN/IN predicates are of
the date/time type the function did not perform conversion of
the constant arguments to the same format as the first field argument.
If formats of the arguments differed it caused wrong a evaluation of
the predicates.
Idea of the fix is for master to send FD event with `created' as 0
to reconnecting slave (upon slave_net_timeout, no master crash) to avoid destroying temp tables.
In a case of a connect by slave to the master after its crash temp tables have been already
cleaned up so that slave can not keep `orphan' temp tables.
The problem was due to the fact that with --lower-case-table-names set to 1
the function find_field_in_group did not convert the prefix 'HU' in
HU.PROJ.CITY into lower case when looking for it in the group list. Yet the
names in the group list were extended by the database name in lower case.
counter".
When TRUNCATE TABLE was called within an stored procedure the
auto_increment counter was not reset to 0 even if straight
TRUNCATE for this table did this.
This fix makes TRUNCATE in stored procedures to be handled exactly
in the same way as straight TRUNCATE. We achieve this by rolling
back the fix for bug 8850, which is no longer needed since stored
procedures don't require prelocked mode anymore (and TRUNCATE is
not allowed in stored functions or triggers).
Additional fix for INSERT DELAYED with subselect.
Originally detected in 5.1, but 5.0 could also be affected.
The user thread creates a dummy table object,
which is not included in the lock. The 'real' table is
opened and locked by the 'delayed' system thread.
The dummy object is now marked as not locked and this is
tested in mysql_lock_have_duplicate().
Mutli-table uses temporary table to store new values for fields. With the
new values the rowid of the record to be updated is stored in a Field_string
field. Table to be updated is set as source table of the rowid field.
But when the temporary table creates the tmp field for the rowid field it
converts it to a varstring field because the table to be updated was created by
the v4.1. Due to this the stored rowids were broken and no records for
update were found.
The flag can_alter_field_type is added to Field_string class. When it is set to
0 the field won't be converted to varstring. The Field_string::type() function
now always returns MYSQL_TYPE_STRING if can_alter_field_type is set to 0.
The multi_update::initialize_tables() function now sets can_alter_field_type
flag to 0 for the rowid fields denying conversion of the field to a varstring
field.
The wrong value was being reported as the field_length for BIT
fields, resulting in confusion for at least Connector/J. The
field_length is now always the number of bits in the field, as
it should be.
The code in opt_sum_query that prevented the COUNT/MIN/MAX
optimization from being applied to outer joins was not adjusted
after introducing nested joins. As a result if an outer join
contained a reference to a view as an inner table the code of
opt_sum_query missed the presence of an on expressions and
erroneously applied the mentioned optimization.
Multiple equalities were not adjusted after reading constant tables.
It resulted in neglecting good index based methods that could be
used to access of other tables.
Fixed BUG#15650: DELETE with LEFT JOIN crashes server
with innodb_locks_unsafe_for_binlog.
Fixed compilation problem with non-C99 compilers
in btr0sea.c
The bug was due to a missed case in the detection of whether an index
can be used for loose scan. More precisely, the range optimizer chose
to use loose index scan for queries for which the condition(s) over
an index key part could not be pushed to the index together with the
loose scan.
As a result, loose index scan was selecting the first row in the
index with a given GROUP BY prefix, and was applying the WHERE
clause after that, while it should have inspected all rows with
the given prefix, and apply the WHERE clause to all of them.
The fix detects and skips such cases.