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

  Fixed typo.

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

The Item::tmp_table_field_from_field_type() function creates Field_datetime
object instead of Field_timestamp object for timestamp field thus always
changing data type is a tmp table is used.

The Field_blob object constructor which is used in the 
Item::tmp_table_field_from_field_type() is always setting packlength field of
newly created blob to 4. This leads to changing fields data type for example
from the blob to the longblob if a temporary table is used.

The Item::make_string_field() function always converts Field_string objects 
to Field_varstring objects. This leads to changing data type from the 
char/binary to varchar/varbinary.

Added appropriate Field_timestamp object constructor for using in the 
Item::tmp_table_field_from_field_type() function.

Added Field_blob object constructor which sets pack length according to
max_length argument.

The Item::tmp_table_field_from_field_type() function now creates
Field_timestamp object for a timestamp field.

The Item_type_holder::display_length() now returns correct NULL length NULL
length. 

The Item::make_string_field() function now doesn't change Field_string to
Field_varstring in the case of Item_type_holder. 

The Item::tmp_table_field_from_field_type() function now uses the Field_blob
constructor which sets packlength according to max_length.

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

 An aggregate function reference was resolved incorrectly and
caused a crash in count_field_types.
 Must use real_item() to get to the real Item instance through
the reference

into  lamia.home:/home/tkatchaounov/autopush/5.0-bug-21007

The problem was that store_top_level_join_columns() incorrectly assumed
that the left/right neighbor of a nested join table reference can be only
at the same level in the join tree.

The fix checks if the current nested join table reference has no immediate
left/right neighbor, and if so chooses the left/right neighbors of the
nearest upper level, where these references are != NULL.

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

for class Item_func_trim. 
For 4.1 it caused wrong output for EXPLAIN EXTENDED commands
if expressions with the TRIM function of two arguments were used.
For 5.0 it caused an error message when trying to select
from a view with the TRIM function of two arguments.
This unexpected error message was due to the fact that the
print method for the class Item_func_trim was inherited from
the class Item_func. Yet the TRIM function does not take a list
of its arguments. Rather it takes the arguments in the form:
  [{BOTH | LEADING | TRAILING} [remstr] FROM] str) |
  [remstr FROM] str

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

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

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

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

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

  Test case for bug#10977 altered to make it work in both plain and ps-protocol modes.

  Corrected the test case after fixing bug#10977

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

  Fixed bug#10977: No warning issued if a column name is truncated
  New warning message is added.

When an alias is set to a column leading spaces are removed from the alias.
But when this is done on aliases set by user this can lead to confusion.

Now Item::set_name() method issues the warning if leading spaces were removed
from an alias set by user.

New warning message is added.

into  orca.ndb.mysql.com:/space_old/pekka/ndb/version/my50

The bug caused a crash of the server if a subquery with
ORDER BY DESC used the range access method.
The bug happened because the method QUICK_SELECT_DESC::reset
was not reworked after MRR interface had been introduced.

The bug was due to a loss happened during a refactoring made
on May 30 2005 that modified the function JOIN::reinit.
As a result of it for any subquery the value of offset_limit_cnt
was not restored for the following executions. Yet the first 
execution of the subquery made it equal to 0.
The fix restores this value in the function JOIN::reinit.  

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

into  anubis.greendragongames.com:/home/greenman/workspace-mysql/mysql/merge-4.1_2_5.0

into  rakia.(none):/home/kgeorge/mysql/autopush/B17212-4.1-opt

Discussed with Kent.

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

DESCRIBE returned the type BIGINT for a column of a view if the column
was specified by an expression over values of the type INT.
    
E.g. for the view defined as follows:
  CREATE VIEW v1 SELECT COALESCE(f1,f2) FROM t1
DESCRIBE returned type BIGINT for the only column of the view if f1,f2 are
columns of the INT type.
At the same time DESCRIBE returned type INT for the only column of the table
defined by the statement:
  CREATE TABLE t2 SELECT COALESCE(f1,f2) FROM t1.
    
This inconsistency was removed by the patch.

Now the code chooses between INT/BIGINT depending on the
precision of the aggregated column type.
 
Thus both DESCRIBE commands above returns type INT for v1 and t2.
 

into  mysql.com:/home/tnurnberg/work/mysql-5.0-21014

mysqldump did not select the correct database before trying to dump
views from it. this resulted in an empty result set, which in turn
startled mysql-dump into a core-dump.  this only happened for views,
not for tables, and was only visible with multiple databases that
weren't by sheer luck in the order mysqldump required, anyway. this
fixes by selecting the correct database before dumping views; it also
catches the empty set-condition if it should occur for other reasons.

into  zippy.(none):/home/cmiller/work/mysql/m41-maint--07AB5

into  zippy.(none):/home/cmiller/work/mysql/m41-maint--07AB5

into  zippy.(none):/home/cmiller/work/mysql/m50--07C2P