After merge fix

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

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

Currently in the ONLY_FULL_GROUP_BY mode no hidden fields are allowed in the
select list. To ensure this each expression in the select list is checked
to be a constant, an aggregate function or to occur in the GROUP BY list.
The last two requirements are wrong and doesn't allow valid expressions like
"MAX(b) - MIN(b)" or "a + 1" in a query with grouping by a.

The correct check implemented by the patch will ensure that:
any field reference in the [sub]expressions of the select list 
  is under an aggregate function or
  is mentioned as member of the group list or
  is an outer reference or
  is part of the select list element that coincide with a grouping element.

The Item_field objects now can contain the position of the select list
expression which they belong to. The position is saved during the
field's Item_field::fix_fields() call.

The non_agg_fields list for non-aggregated fields is added to the SELECT_LEX
class. The SELECT_LEX::cur_pos_in_select_list now contains the position in the
select list of the expression being currently fixed.

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

           aliases ignored
When a column reference to a column in JOIN USING is resolved and a new 
Item is created for this column the user defined name was lost.
This fix preserves the alias by setting the name of the new Item to the
original alias.

correctly.

The Item_func::print method was used to print the Item_func_encode and the
Item_func_decode objects. The last argument to ENCODE and DECODE functions
is a plain C string and thus Item_func::print wasn't able to print it.

The print() method is added to the Item_func_encode class. It correctly
prints the Item_func_encode and the Item_func_decode objects.

WHERE is present.

If a DELETE statement with ORDER BY and LIMIT contains a WHERE clause
with conditions that for sure cannot be used for index access (like in
WHERE @var:= field) the execution always follows the filesort path.    
It happens currently even when for the above case there is an index that
can be used to speedup sorting by the order by list.

Now if a DELETE statement with ORDER BY and LIMIT contains such WHERE
clause conditions that cannot be used to build any quick select then
the mysql_delete() tries to use an index like there is no WHERE clause at all.

into  mysql.com:/d2/hf/mr10/my50-mr10

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

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

into  mysql.com:/d2/hf/mr10/my50-mr10

  Removed line accidently inserted when correcting bug#18526

into  mysql.com:/d2/hf/mr10/my50-mr10

into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt

2nd version
During tmp tables cleanup we get the handler for temporary table
and delete table using handler method.

In the method Item_field::fix_fields we try to resolve the name of
the field against the names of the aliases that occur in the select
list. This is done by a call of the function find_item_in_list.
When this function finds several occurrences of the field name
it sends an error message to the error queue and returns 0.
Yet the code did not take into account that find_item_in_list
could return 0 and tried to dereference the returned value.

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

support-files/MySQL-shared-compat.spec.sh  :    Dummy, irrelevant change - just trigger a new build.

used.

The Item::save_in_field() function is called from fill_record() to fill the 
new row with data while execution of the CREATE TABLE ... SELECT statement.
Item::save_in_field() calls val_xxx() methods in order to get values.
val_xxx() methods do not take into account the result field. Due to this
Item_func_set_user_var::val_xxx() methods returns values from the original
table, not from the temporary one.

The save_in_field() member function is added to the Item_func_set_user_var
class. It detects whether the result field should be used and properly updates
the value of the user variable.

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

A BINARY field is represented by the Field_string class. The space character
is used as the filler for unused characters in such a field. But a BINARY field 
should use \x00 instead.

Field_string:reset() now detects whether the current field is a BINARY one
and if so uses the \x00 character as a default value filler.

into  moonbone.local:/home/evgen/bk-trees/mysql-5.0-opt

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

into  kpdesk.mysql.com:/home/thek/dev/mysql-5.0-build

into  mysql.com:/d2/hf/opt/my50-opt

into  kpdesk.mysql.com:/home/thek/dev/bug23010/my50-bug23010

into  kpdesk.mysql.com:/home/thek/dev/bug23010/my41-fix23010

into  moonbone.local:/home/evgen/bk-trees/mysql-5.0-opt

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

into  mysql.com:/d2/hf/opt/my50-opt

into  mysql.com:/home/kent/bk/tmp/mysql-5.0-build

  Add CFLAGS to gcc call with --print-libgcc-file, to make sure the
  correct "libgcc.a" path is returned for the 32/64 bit architecture

  The optimizer removes expressions from GROUP BY/DISTINCT
  if they happen to participate in a <expression> = <const>
  predicates of the WHERE clause (the idea being that if
  it's always equal to a constant it can't have multiple 
  values).
  However for predicates where the expression and the 
  constant item are of different result type this is not
  valid (e.g. a string column compared to 0).
  Fixed by additional check of the result types of the 
  expression and the constant and if they differ the 
  expression don't get removed from the group by list.

into  tiger.mmj.dk:/Users/mmj/bktrees/mysql-5.0-build

  Patch from Alfredo for TARGET_FAT_BINARY

into  tiger.mmj.dk:/Users/mmj/bktrees/mysql-5.0-build