list using a function
When executing dependent subqueries they are re-inited and re-exec() for 
each row of the outer context.
The cause for the bug is that during subquery reinitialization/re-execution,
the optimizer reallocates JOIN::join_tab, JOIN::table in make_simple_join()
and the local variable in 'sortorder' in create_sort_index(), which is
allocated by make_unireg_sortorder().
Care must be taken not to allocate anything into the thread's memory pool
while re-initializing query plan structures between subquery re-executions.
All such items mush be cached and reused because the thread's memory pool
is freed at the end of the whole query.
Note that they must be cached and reused even for queries that are not 
otherwise cacheable because otherwise it will grow the thread's memory 
pool every time a cacheable query is re-executed. 
We provide additional members to the JOIN structure to store references 
to the items that need to be cached.

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.  

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  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  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

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

into  zippy.cornsilk.net:/home/cmiller/work/mysql/merge/mysql-5.0

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

into  sunlight.local:/local_work/16861-bug-5.0-mysql

used.

Sorting by RAND() uses a temporary table in order to get a correct results.
User defined variable was set during filling the temporary table and later
on it is substituted for its value from the temporary table. Due to this
it contains the last value stored in the temporary table.

Now if the result_field is set for the Item_func_set_user_var object it 
updates variable from the result_field value when being sent to a client.

The Item_func_set_user_var::check() now accepts a use_result_field
parameter. Depending on its value the result_field or the args[0] is used
to get current value.

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

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

when X.509 subject was required for a connect, we tested whether it was the right
one, but did not refuse the connexion if not. fixed.

(corrected CS now --replace_results socket-path)

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