an ALL/ANY quantified subquery in HAVING.
The Item::split_sum_func2 method should not create Item_ref
for objects of any class derived from Item_subselect.
Any default value for a enum fields over UCS2 charsets was corrupted
when we put it into the frm file, as it had been overwritten by its
HEX representation.
To fix it now we save a copy of structure that represents the enum
type and when putting the default values we use this copy.
statement that uses an aggregating IN subquery with
HAVING clause.
A wrong order of the call of split_sum_func2 for the HAVING
clause of the subquery and the transformation for the
subquery resulted in the creation of a andor structure
that could not be restored at an execution of the prepared
statement.
Removed changes to the Item_func_between::fix_length_and_dec() made in the fix for bug#16377
query_cache.result:
Corrected a test case after removing a fix for bug#16377
VALUES() was considered a constant. This caused replacing
(or pre-calculating) it using uninitialized values before the actual
execution takes place.
Mark it as a non-constant (still not dependent of tables) to prevent
the pre-calculation.
Corrected test case after removal of fix for bug#16377
type_date.test:
Corrected test case after removal of fix for bug#16377
item_cmpfunc.cc:
Removed changes to the agg_cmp_type() made in the for bug#16377
1003: Incorrect table name
in multi-table DELETE the set of tables to delete from actually
references then tables in the other list, e.g:
DELETE alias_of_t1 FROM t1 alias_of_t1 WHERE ....
is a valid statement.
So we must turn off table name syntactical validity check for alias_of_t1
because it's not a table name (even if it looks like one).
In order to do that we add a special flag (TL_OPTION_ALIAS) to
disable the name checking for the aliases in multi-table DELETE.
The problem was due to a prior fix for BUG 9676, which limited
the rows stored in a temporary table to the LIMIT clause. This
optimization is not applicable to non-group queries with aggregate
functions. The fix disables the optimization in this case.
event' from master"
Since there is no repeatable test case, and this is obviously wrong, this is
the most conservative change that might possibly work.
The syscall read() wasn't checked for a negative return value for an
interrupted read. The kernel sys_read() returns -EINTR, and the "library"
layer maps that to return value of -1 and sets errno to EINTR. It's
impossible (on Linux) for read() to set errno EINTR without the return
value being -1 .
So, if we're checking for EINTR behavior, we should not require that the
return value be zero.
