prepared statement and subquery.

When a field of a view from an outer select is resolved the find_field_in_view
function creates an Item_direct_view_ref object that references the 
corresponding view underlying field. After that the view_ref is marked
as a dependent one. While resolving view underlying field it also get
marked as a dependent one due to current_select still points to the subselect.
Marking the view underlying field is wrong and lead to attaching conditions
to a wrong table and thus to the wrong result of the whole statement.

Now mark_select_range_as_dependent() function isn't called for fields from a 
view underlying table.

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

When compiling GROUP BY Item_ref instances are dereferenced in 
setup_copy_fields(), i.e. replaced with the corresponding Item_field 
(if they point to one) or Item_copy_string for the other cases.
Since the Item_ref (in the Item_field case) is no longer used the information
about the aliases stored in it is lost.   
Fixed by preserving the column, table and DB alias on dereferencing Item_ref

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

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

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/8663/my50-8663

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

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

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

decimal->ulong conversion fixed to assign max possible ULONG if decimal
is bigger
Item_func_unsigned now handles DECIMAL parameter separately as we can't
rely on decimal::val_int result here.

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