This bug was intruduced by the fix for bug#17212 (in 4.1). It is not
ok to call test_if_skip_sort_order since this function will
alter the execution plan. By contract it is not ok to call
test_if_skip_sort_order in this context.
This bug appears only in the case when the optimizer has chosen
an index for accessing a particular table but finds a covering
index that enables it to skip ORDER BY. This happens in
test_if_skip_sort_order.
It was syntactically correct to define
spatial keys over parts of columns (e.g.
ALTER TABLE t1 ADD x GEOMETRY NOT NULL,
ADD SPATIAL KEY (x(32))).
This may lead to undefined results and/or
interpretation.
Fixed by not allowing partial column
specification in a SPATIAL index definition.
Different set of conditions is used to verify
the validity of index definitions over a GEOMETRY
column in ALTER TABLE and CREATE TABLE.
The difference was on how sub-keys notion validity
is checked.
Fixed by extending the CREATE TABLE condition to
support the cases allowed in ALTER TABLE.
Made the SHOW CREATE TABLE not to display spatial
indexes using the sub-key notion.
When the SUBSTRING() function was used over a LONGTEXT field the max_length of
the SUBSTRING() result was wrongly calculated and set to 0. As the max_length
parameter is used while tmp field creation it limits the length of the result
field and leads to printing an empty string instead of the correct result.
Now the Item_func_substr::fix_length_and_dec() function correctly calculates
the max_length parameter.
construct references invalid name.
Derived tables currently cannot use outer references.
Thus there is no outer context for them.
The 4.1 code takes this fact into account while the
Item_field::fix_outer_field code of 5.0 lost the check that blocks
any attempts to resolve names in outer context for derived tables.
result.
For built-in functions like sqrt() function names are hard-coded and can be
compared by pointer. But this isn't the case for a used-defined stored
functions - names there are dynamical and should be compared as strings.
Now the Item_func::eq() function employs my_strcasecmp() function to compare
used-defined stored functions names.
away.
During optimization stage the WHERE conditions can be changed or even
be removed at all if they know for sure to be true of false. Thus they aren't
showed in the EXPLAIN EXTENDED which prints conditions after optimization.
Now if all elements of an Item_cond were removed this Item_cond is substituted
for an Item_int with the int value of the Item_cond.
If there were conditions that were totally optimized away then values of the
saved cond_value and having_value will be printed instead.
Functions over sum functions wasn't set up correctly for the ORDER BY clause
which leads to a wrong order of the result set.
The split_sum_func() function is called now for each ORDER BY item that
contains a sum function to set it up correctly.
