into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt

The cause of the bug was an incomplete fix for bug 18080.
The problem was that setup_tables() unconditionally reset the
name resolution context to its 'tables' argument, which pointed
to the first table of an SQL statement.

The bug fix limits resetting of the name resolution context in
setup_tables() only in the cases when the context was not set
by earlier parser/optimizer phases.

into  rakia.(none):/home/kgeorge/mysql/autopush/B21772-5.0-opt

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

Upgrade was a reserved word. Unreserve UPGRADE so it can be used in unquoted identifiers.

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

equal constant under any circumstances.
In fact this substitution can be allowed if the field is
not of a type string or if the field reference serves as 
an argument of a comparison predicate.  

Select_type in the EXPLAIN output for the query SELECT * FROM t1 was
'SIMPLE', while for the query SELECT * FROM v1, where the view v1
was defined as SELECT * FROM t1, the EXPLAIN output contained 'PRIMARY'
for the select_type column.
 

into  macbook.gmz:/Users/kgeorge/mysql/work/B16792-5.0-opt

into  rakia.(none):/home/kgeorge/mysql/autopush/B21392-5.0-opt

into  macbook.gmz:/Users/kgeorge/mysql/work/B21392-5.0-opt

            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.

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

into  rakia.(none):/home/kgeorge/mysql/autopush/B14654-5.0-opt

account by the optimizer.
Now all row equalities are converted into conjunctions of
equalities between row elements. They are taken into account
by the optimizer together with the original regular equality
predicates.

into  mysql.com:/home/psergey/mysql-5.0-bug21477-look-64bit

make st_select_lex::setup_ref_array() take into account that 
Item_sum-descendant objects located within descendant SELECTs
may be added into ref_pointer_array.

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

 Made the parser to support parenthesis around UNION branches.
 This is done by amending the rules of the parser so it generates the correct
 structure.
 Currently it supports arbitrary subquery/join/parenthesis operations in the 
 EXISTS clause. 
 In the IN/scalar subquery case it will allow adding nested parenthesis only 
 if there is an UNION clause after the parenthesis. Otherwise it will just  
 treat the multiple nested parenthesis as a scalar expression.
 It adds extra lex level for ((SELECT ...) UNION ...) to accommodate for the
 UNION clause.

when a range condition use an invalid DATETIME constant.
Now we do not use invalid DATETIME constants to form end keys for
range intervals: range analysis just ignores predicates with such
constants.  

into  dl145s.mysql.com:/data/tkatchaounov/autopush/5.0-bug-21456

into  moonbone.local:/work/tmp_merge-5.0-mysql

into  moonbone.local:/work/tmp_merge-4.1-opt-mysql

into  moonbone.local:/work/tmp_merge-5.0-mysql

into  mysql.com:/home/psergey/mysql-5.0-bug16255-merge

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

const tables. This resulted in choosing extremely inefficient
execution plans in same cases when distribution of data in
joined were skewed (see the customer test case for the bug).

  Corrected fix for bug#18165

  Corrected fix for bug#18165

 Must not use Item_direct_ref in HAVING because it points to
 the new value (witch is not yet calculated for the first row).

  Corrected test case for the bug#21261
sql_parse.cc:
  Corrected fix for bug#21261

into  lamia.home:/home/timka/mysql/src/5.0-bug-21456

GROUP BY/DISTINCT pruning optimization must be done before ORDER BY 
optimization because ORDER BY may be removed when GROUP BY/DISTINCT
sorts as a side effect, e.g. in 
  SELECT DISTINCT <non-key-col>,<pk> FROM t1
  ORDER BY <non-key-col> DISTINCT
must be removed before ORDER BY as if done the other way around
it will remove both.

into  moonbone.local:/work/21475-fix-5.0-opt-mysql

  Additional fix for bug #21475
item_func.h, item_func.cc:
  Additional fix for bug#16861

into  salvation.intern.azundris.com:/home/tnurnberg/work/mysql-5.0-maint-20987