into  mysql.com:/home/hf/work/mysql-5.1.clean

into  mysql.com:/home/psergey/mysql-5.0-bug8804-pfix

Don't assume that condition that was pushed down into subquery has 
produced exactly one KEY_FIELD element - it could produce several or
none at all, handle all of those cases.

into  rakia.gmz:/home/kgeorge/mysql/autopush/B11032-5.0-opt

into  mysql.com:/home/hf/work/mysql-5.0.clean

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

 - When returning metadata for scalar subqueries the actual type of the
   column was calculated based on the value type, which limits the actual
   type of a scalar subselect to the set of (currently) 3 basic types : 
   integer, double precision or string. This is the reason that columns
   of types other then the basic ones (e.g. date/time) are reported as
   being of the corresponding basic type.
   Fixed by storing/returning information for the column type in addition
   to the result type.

  merge fixes

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

into  mysql.com:/home/hf/work/21790/my50-21790

into  mysql.com:/home/hf/work/19491/my50-19491

 The parser is allocating Item_field for references by name in ORDER BY
 expressions. Such expressions however may point not only to Item_field 
 in the select list (or to a table column) but also to an arbitrary Item. 
 This causes Item_field::fix_fields to throw an error about missing 
 column.
 The fix substitutes Item_field for the reference with an Item_ref when 
 not pointing to Item_field.

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

into  mysql.com:/home/hf/work/21790/my51-21790

into  mysql.com:/home/hf/work/21790/my51-21790

into  mysql.com:/home/hf/work/mysql-5.0.19491

This is a performance issue for queries with subqueries evaluation
of which requires filesort.
Allocation of memory for the sort buffer at each evaluation of a
subquery may take a significant amount of time if the buffer is rather big.
With the fix we allocate the buffer at the first evaluation of the
subquery and reuse it at each subsequent evaluation.

into  mysql.com:/home/psergey/mysql-5.0-bug8804-r4

- Better comments
- Remove redundant and dead code.

the fix. 

Evaluate "NULL IN (SELECT ...)" in a special way: Disable pushed-down 
conditions and their "consequences": 
 = Do full table scans instead of unique_[index_subquery] lookups.
 = Change appropriate "ref_or_null" accesses to full table scans in
   subquery's joins.
Also cache value of NULL IN (SELECT ...) if the SELECT is not correlated 
wrt any upper select.

into  mysql.com:/usersnfs/abotchkov/mysql-5.0-opt1

into  rakia.gmz:/home/kgeorge/mysql/autopush/B21809-5.0-opt

into  rakia.gmz:/home/kgeorge/mysql/autopush/B23184-5.0-opt

 Item::val_xxx() may be called by the server several times at execute time 
 for a single query. Calls to val_xxx() may be very expensive and sometimes
 (count(distinct), sum(distinct), avg(distinct)) not possible.
 To avoid that problem the results of calculation for these aggregate 
 functions are cached so that val_xxx() methods just return the calculated 
 value for the second and subsequent calls.

into  mysql.com:/usersnfs/abotchkov/mysql-4.1-opt1

into  mysql.com:/usersnfs/abotchkov/mysql-5.0-opt1

into  mysql.com:/home/hf/work/current_stmt/my50-current_stmt

into  mysql.com:/usersnfs/abotchkov/mysql-5.1-opt1

into  mysql.com:/home/hf/work/0current_stmt/my41-current_stmt

into  mysql.com:/home/hf/work/current_stmt/my51-current_stmt