Certain updates of table joined to self results in unexpected
behavior.
The problem was that record cache was mistakenly enabled for
self-joined table updates. Normally record cache must be disabled
for such updates.
Fixed wrong condition in code that determines whether to use
record cache for self-joined table updates.
Only MyISAM tables were affected.
INSERT triggers".
In cases when REPLACE was internally executed via update and table had
on update (on delete) triggers defined we exposed the fact that such
optimization used by callng on update (not calling on delete) triggers.
Such behavior contradicts our documentation which describes REPLACE as
INSERT with optional DELETE.
This fix just disables this optimization for tables with on delete triggers.
The optimization is still applied for tables which have on update but have
no on delete triggers, we just don't invoke on update triggers in this case
and thus don't expose information about optimization to user.
Also added test coverage for values returned by ROW_COUNT() function (and
thus for values returned by mysql_affected_rows()) for various forms of
INSERT.
resulted in a wrong error message.
The nest_level counter indicates the depth of nesting for a subselect. It is
needed to properly resolve aggregate functions in nested subselects. Obviously
it shouldn't be incremented for UNION parts because they have the same level of
nesting. This counter was incremented by 1 in the mysql_new_select() function
for any new select and wasn't decremented for UNION parts. This resulted in
wrongly reported error messages.
Now the nest_level counter is decremented by 1 for any union part.
The Field::eq() considered instances of Field_bit that differ only in
bit_ptr/bit_ofs equal. This caused equality conditions optimization
(build_equal_items_for_cond()) to make bad field substitutions that result
in wrong predicates.
Field_bit requires an overloaded eq() function that checks the bit_ptr/bit_ofs
in addition to Field::eq().
This bug in Field_string::cmp resulted in a wrong comparison
with keys in partial indexes over multi-byte character fields.
Given field a is declared as
a varchar(16) collate utf8_unicode_ci
INDEX(a(4)) gives us an example of such an index.
Wrong key comparisons could lead to wrong result sets if
the selected query execution plan used a range scan by
a partial index over a utf8 character field.
This also caused wrong results in many other cases.
