aliases ignored
When a column reference to a column in JOIN USING is resolved and a new
Item is created for this column the user defined name was lost.
This fix preserves the alias by setting the name of the new Item to the
original alias.
In the method Item_field::fix_fields we try to resolve the name of
the field against the names of the aliases that occur in the select
list. This is done by a call of the function find_item_in_list.
When this function finds several occurrences of the field name
it sends an error message to the error queue and returns 0.
Yet the code did not take into account that find_item_in_list
could return 0 and tried to dereference the returned value.
used.
The Item::save_in_field() function is called from fill_record() to fill the
new row with data while execution of the CREATE TABLE ... SELECT statement.
Item::save_in_field() calls val_xxx() methods in order to get values.
val_xxx() methods do not take into account the result field. Due to this
Item_func_set_user_var::val_xxx() methods returns values from the original
table, not from the temporary one.
The save_in_field() member function is added to the Item_func_set_user_var
class. It detects whether the result field should be used and properly updates
the value of the user variable.
A BINARY field is represented by the Field_string class. The space character
is used as the filler for unused characters in such a field. But a BINARY field
should use \x00 instead.
Field_string:reset() now detects whether the current field is a BINARY one
and if so uses the \x00 character as a default value filler.
The optimizer removes expressions from GROUP BY/DISTINCT
if they happen to participate in a <expression> = <const>
predicates of the WHERE clause (the idea being that if
it's always equal to a constant it can't have multiple
values).
However for predicates where the expression and the
constant item are of different result type this is not
valid (e.g. a string column compared to 0).
Fixed by additional check of the result types of the
expression and the constant and if they differ the
expression don't get removed from the group by list.
This bug appeared after the patch for bug 21390 that had added some code
to handle outer joins with no matches after substitution of a const
table in an efficient way. That code as it is cannot be applied to the case
of nested outer join operations. Being applied to the queries with
nested outer joins the code can cause crashes or wrong result sets.
The fix blocks row substitution for const inner tables of an outer join
if the inner operand is not a single table.
repair it
Multi-table delete that is optimized with QUICK_RANGE reports table
corruption.
DELETE statement must not use KEYREAD optimization, and sets
table->no_keyread to 1. This was ignored in QUICK_RANGE optimization.
With this fix QUICK_RANGE optimization honors table->no_keyread
value and does not enable KEYREAD when it is requested.
When only one row was present, the subtraction of nearly the same number
resulted in catastropic cancellation, introducing an error in the
VARIANCE calculation near 1e-15. That was sqrt()ed to get STDDEV, the
error was escallated to near 1e-8.
The simple fix of testing for a row count of 1 and forcing that to yield
0.0 is insufficient, as two rows of the same value should also have a
variance of 0.0, yet the error would be about the same.
So, this patch changes the formula that computes the VARIANCE to be one
that is not subject to catastrophic cancellation.
In addition, it now uses only (faster-than-decimal) floating point numbers
to calculate, and renders that to other types on demand.
Handling of large signed/unsigned values was not consistent, so some string functions could return bogus results.
The current fix is to simply patch up the val_str() methods for those string items.
It would be good clean this code up in general, to make similar problems much harder to make. This is left as an exercise for the reader.
spatial index
While executing OPTIMIZE TABLE on MyISAM tables the server re-creates the
index file(s) in order to sort them physically by the key. This cannot be
done for R-tree indexes as it makes no sense.
The server was not checking the type of the index and was accessing an
R-tree index as if it was a B-tree.
Fixed by preventing sorting the index file if it contains an R-tree index.
If SELECT-part of CREATE VIEW statement contains '\Z',
it is not handled correctly.
The problem was in String::print().
Symbol with code 032 (26) is replaced with '\z',
which is not supported by the lexer.
The fix is to replace the symbol with '\Z'.
the UDF
When deleting a user defined function MySQL must remove it from both the
in-memory hash table and the mysql.proc system table.
Finding (and removal therefore) from the internal hash table is case
insensitive (or whatever the default charset is), whereas finding and
removal from the system table is case sensitive.
As a result if you supply a function name that is not in the same character
case to DROP FUNCTION the server will remove the function only from the
in-memory hash table and will keep the row in mysql.proc system table.
This will cause inconsistency between the two structures (that is fixed
only by restarting the server).
Fixed by using the name in the precise case (from the in-memory hash table)
to delete the row in the mysql.proc system table.
