into moonbone.local:/work/15962-bug-5.0-opt-mysql

into  rurik.mysql.com:/home/igor/mysql-5.0-opt

into  mysql.com:/home/kgeorge/mysql/5.0/B15355

  query
Problem:
There was a wrong context assigned to the columns that were added in insert_fields()
when expanding a '*'. When this is done in a prepared statement it causes 
fix_fields() to fail to find the table that these columns reference.
Actually the right context is set in setup_natural_join_row_types() called at the 
end of setup_tables(). However when executed in a context of a prepared statement
setup_tables() resets the context, but setup_natural_join_row_types() was not
setting it to the correct value assuming it has already done so.

Solution:
The top-most, left-most NATURAL/USING join must be set as a 
first_name_resolution_table in context even when operating on prepared statements.

To calculate its max_length the CONCAT() function is simply sums max_lengths
of its arguments but when the collation of an argument differs from the 
collation of the CONCAT() max_length will be wrong. This may lead to a data
truncation when a tmp table is used, in UNIONS for example.

The Item_func_concat::fix_length_and_dec() function now recalculates the 
max_length of an argument when the mbmaxlen of the argument differs from the
mbmaxlen of the CONCAT().

into  rurik.mysql.com:/home/igor/mysql-5.0-opt

into  rurik.mysql.com:/home/igor/mysql-4.1-opt

The bug report revealed two problems related to min/max optimization:
1. If the length of a constant key used in a SARGable condition for
for the MIN/MAX fields is greater than the length of the field an 
unwanted warning on key truncation is issued;
2. If MIN/MAX optimization is applied to a partial index, like INDEX(b(4))
than can lead to returning a wrong result set.

into  mysql.com:/home/kgeorge/mysql/5.0/B4981

        3.23 regression test failure

The member SEL_ARG::min_flag was not initialized, 
due to which the condition for no GEOM_FLAG in function 
key_or did not choose "Range checked for each record" as 
the correct access method.

  After merge fix

into moonbone.local:/work/18360-bug-4.1-mysql-opt

The IN() function uses agg_cmp_type() to aggregate all types of its arguments
to find out some common type for comparisons. In this particular case the 
char() and the int was aggregated to double because char() can contain values
like '1.5'. But all strings which do not start from a digit are converted to
0. thus 'a' and 'z' become equal. 
This behaviour is reasonable when all function arguments are constants. But 
when there is a field or an expression this can lead to false comparisons. In
this case it makes more sense to coerce constants to the type of the field
argument.

The agg_cmp_type() function now aggregates types of constant and non-constant
items separately. If some non-constant items will be found then their
aggregated type will be returned. Thus after the aggregation constants will be
coerced to the aggregated type. 

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  devsrv-b.mysql.com:/users/msvensson/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  shellback.(none):/home/msvensson/mysql/mysql-5.0

into  devsrv-b.mysql.com:/users/msvensson/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  mysql.com:/usr/home/ram/work/mysql-5.0

In multi-table delete a table for delete can't be used for selecting in
subselects. Appropriate error was raised but wasn't checked which leads to a
crash at the execution phase.

The mysql_execute_command() now checks for errors before executing select
for multi-delete.

into  mysql.com:/home/emurphy/iggy/mysql-5.0

into  mysql.com:/home/kgeorge/mysql/5.0/clean

into  mysql.com:/home/kgeorge/mysql/5.0/B18681

into  mysql.com:/home/kgeorge/mysql/5.0/B18681

into  mysql.com:/home/kgeorge/mysql/5.0/B14875

When reading a view definition from a .frm file it was
throwing a SQL error if the DEFINER user is not defined.
Changed it to a warning to match the (documented) case
when a view with undefined DEFINER user is created.

The check for view security was lacking several points :
1. Check with the right set of permissions : for each table ref that
participates in a view there were the right credentials to use in it's
security_ctx member, but these weren't used for checking the credentials.
This makes hard enforcing the SQL SECURITY DEFINER|INVOKER property
consistently.
2. Because of the above the security checking for views was just ruled out
in explicit ways in several places.
3. The security was checked only for the columns of the tables that are
brought into the query from a view. So if there is no column reference
outside of the view definition it was not detecting the lack of access to
the tables in the view in SQL SECURITY INVOKER mode.

The fix below tries to fix the above 3 points.