Two problems here:

 Problem 1:

 While constructing the join columns list the optimizer does as follows:
  1. Sets the join_using_fields/natural_join members of the right JOIN 
   operand.
  2. Makes a "table reference" (TABLE_LIST) to parent the two tables.
  3. Assigns the join_using_fields/is_natural_join of the wrapper table
   using join_using_fields/natural_join of the rightmost table
  4. Sets join_using_fields to NULL for the right JOIN operand.
  5. Passes the parent table up to the same procedure on the upper 
   level.

 Step 1 overrides the the join_using_fields that are set for a nested 
 join wrapping table in step 4.
 Fixed by making a designated variable SELECT_LEX::prev_join_using to 
 pass the data from step 1 to step 4 without destroying the wrapping 
 table data.

 Problem 2:

 The optimizer checks for ambiguous columns while transforming 
 NATURAL JOIN/JOIN USING to JOIN ON. While doing that there was no
 distinction between columns that are used in the generated join
 condition (where ambiguity can be checked) and the other columns
 (where ambiguity can be checked only when resolving references
 coming from outside the JOIN construct itself).
 Fixed by allowing the non-USING columns to be present in multiple 
 copies in both sides of the join and moving the ambiguity check 
 to the place where unqualified references to the join columns are
 resolved (find_field_in_natural_join()).


mysql-test/r/join_nested.result:
  BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
   - test case
mysql-test/t/join_nested.test:
  BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
   - test case
sql/mysql_priv.h:
  BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
   - use SELECT_LEX to store the ref to JOIN USING list needed by the 
     parser
sql/sql_base.cc:
  BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
   - proper check for duplicate cols
   - more detailed debug output
sql/sql_lex.h:
  BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
   - use SELECT_LEX to store the ref to JOIN USING list needed by the 
     parser
sql/sql_parse.cc:
  BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
   - proper check for duplicate cols in JOIN USING
sql/sql_yacc.yy:
  BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
   - use SELECT_LEX to store the ref to JOIN USING list needed by the 
     parser
sql/table.cc:
  BUG#25575: ERROR 1052 (Column in from clause is ambiguous) with sub-join
   - return null if no table ref (as in nested join columns).

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

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

  Fix for crashes on 64bit platforms after fixing bug#23417.


sql/sql_select.cc:
  Fix for crashes on 64bit platforms after fixing bug#23417.

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


mysql-test/r/range.result:
  Auto merged
mysql-test/t/range.test:
  Auto merged
sql/opt_range.h:
  Manual merge.

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


sql/item_cmpfunc.h:
  Auto merged

 The optimizer needs to evaluate whether predicates are better
 evaluated using an index. IN is one such predicate.
 To qualify an IN predicate must involve a field of the index
 on the left and constant arguments on the right.
 However whether an expression is a constant can be determined only
 by knowing the preceding tables in the join order. 
 Assuming that only IN predicates with expressions on the right that
 are constant for the whole query qualify limits the scope of 
 possible optimizations of the IN predicate (more specifically it
 doesn't allow the "Range checked for each record" optimization for
 such an IN predicate.
 Fixed by not pre-determining the optimizability of the IN predicate
 in the case when all right IN operands are not SQL constant expressions


mysql-test/r/func_in.result:
  BUG#20420: optimizer reports wrong keys on left join with IN
   - test case
mysql-test/t/func_in.test:
  BUG#20420: optimizer reports wrong keys on left join with IN
   - test case
sql/item_cmpfunc.h:
  BUG#20420: optimizer reports wrong keys on left join with IN
   - cannot decide on the optimizability of a function without
     knowing the tables before it in the join order

for queries using 'range checked for each record'.
The problem was fixed in 5.0 by the patch for bug 12291.
This patch down-ported the corresponding code from 5.0 into 
QUICK_SELECT::init() and added a new test case. 


mysql-test/r/range.result:
  Added a test case for bug #24776.
mysql-test/t/range.test:
  Added a test case for bug #24776.
sql/opt_range.h:
  Fixed bug #24776: an assertion abort in handler::ha_index_init
  for queries using 'range checked for each record'.
  The problem was fixed in 5.0 by the patch for bug 12291.
  The patch for 4.1 down-ported the corresponding code from 5.0 into 
  QUICK_SELECT::init().

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

in a select list.
The objects of the Item_trigger_field class inherited the implementations
of the methods copy_or_same, get_tmp_table_item and get_tmp_table_field
from the class Item_field while they rather should have used the default
implementations defined for the base class Item.
It could cause catastrophic problems for triggers that used SELECTs
with select list containing trigger fields such as NEW.<table column>
under DISTINCT.


mysql-test/r/trigger.result:
  Added a test case for bug #25398.
mysql-test/t/trigger.test:
  Added a test case for bug #25398.

  After merge fix


mysql-test/r/func_str.result:
  After merge fix

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


mysql-test/t/func_str.test:
  Auto merged
sql/item_strfunc.cc:
  Auto merged
sql/item_strfunc.h:
  Auto merged
sql/sql_delete.cc:
  Auto merged
mysql-test/r/delete.result:
  Manual merge
mysql-test/r/func_str.result:
  Manual merge
mysql-test/t/delete.test:
  Manual merge

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


sql/sql_base.cc:
  Auto merged

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.


sql/item.cc:
  Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
  The Item_field objects now contain the position of the select list
  expression which they belong to. The position is saved at the field's
  Item_field::fix_fields() call.
sql/item.h:
  Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
  The Item_field objects now can store the position in the select list of the
  expression to which they are belongs to.
sql/mysql_priv.h:
  Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
  Added the UNDEF_POS constant.
sql/sql_base.cc:
  Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
  Now the setup_fields() function maintains the cur_pos_in_select_list variable.
sql/sql_lex.cc:
  Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
  Set the cur_pos_in_select_list variable and the non_agg_fields list to their initial state.
sql/sql_lex.h:
  Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
  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 stores the position in the
  select list of the expression being currently fixed.
sql/sql_select.cc:
  Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
  Each select now keeps the list of fields that aren't
  used under any aggregate function. If an expression from the select list
  isn't found in the GROUP BY list the setup_group() function additionally
  checks whether non-aggregated fields occur in that expression.
  If there at least one such field and it isn't found in the GROUP BY list
  then an error is thrown.
sql/sql_union.cc:
  Bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
  Clean up of the non_agg_fields list.
mysql-test/r/group_by.result:
  Added a test case for the bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.
mysql-test/t/group_by.test:
  Added a test case for the bug#23417: Too strict checks against GROUP BY in the ONLY_FULL_GROUP_BY mode.

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


sql/sql_base.cc:
  Auto merged

           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.


mysql-test/r/join.result:
  BUG#25106: A USING clause in combination with a VIEW results in column
             aliases ignored
   - test case
mysql-test/t/join.test:
  BUG#25106: A USING clause in combination with a VIEW results in column
             aliases ignored
   - test case
sql/sql_base.cc:
  BUG#25106: A USING clause in combination with a VIEW results in column
             aliases ignored
   - take the alias of the Item to be replaced and set it into the newly
     allocated Item.

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.


mysql-test/t/func_str.test:
  Added a test case for bug#23409: Arguments of the ENCODE() and the
  > DECODE() functionswere not printed correctly.
mysql-test/r/func_str.result:
  Added a test case for bug#23409: Arguments of the ENCODE() and the DECODE() functions were not printed correctly.
sql/item_strfunc.h:
  Bug#23409: Arguments of the ENCODE() and the DECODE() functions were not printed correctly.
  The print() method is added to the Item_func_encode class.
sql/item_strfunc.cc:
  Bug#23409: Arguments of the ENCODE() and the DECODE() functions were not printed correctly.
  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.


mysql-test/t/delete.test:
  Added a test case for bug#17711: DELETE doesn't use index when ORDER BY, LIMIT and non-restricting
  WHERE is present.
mysql-test/r/delete.result:
  Added a test case for bug#17711: DELETE doesn't use index when ORDER BY, LIMIT and non-restricting WHERE is present.
sql/sql_delete.cc:
  Bug#17711: DELETE doesn't use index when ORDER BY, LIMIT and non-restricting WHERE is present.
  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


sql/mysqld.cc:
  Auto merged

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

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


sql/item.cc:
  Auto merged
mysql-test/r/order_by.result:
  Manual merge
mysql-test/t/order_by.test:
  Manual merge

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

  Removed line accidently inserted when correcting bug#18526


configure.in:
  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


sql/mysqld.cc:
  Auto merged
sql/sql_base.cc:
  Auto merged
sql/mysql_priv.h:
  manual merge

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


sql/mysql_priv.h:
  added function prototype
sql/mysqld.cc:
  added call of mysql_rm_tmp_tables() function
sql/sql_base.cc:
  mysql_rm_tmp_tables()
  -removed from table_cache_init
  -During tmp tables cleanup we get the handler for temporary table
   and delete table using handler method. 
   it allows to remove orphan records from data dictionary(InnoDB)

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.


mysql-test/r/order_by.result:
  Added a test case for bug #25427.
mysql-test/t/order_by.test:
  Added a test case for bug #25427.
sql/item.cc:
  Fixed bug #25427.
  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.


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.


sql/item_func.cc:
  Bug#16861: User defined variable can have a wrong value if a tmp table was used.
  Added the save_in_field() member function to the Item_func_set_user_var class.
sql/item_func.h:
  Bug#16861: User defined variable can have a wrong value if a tmp table was used.
  Added the save_in_field() member function to the Item_func_set_user_var class.
mysql-test/r/user_var.result:
  Extended the test case for bug#18681: User defined variable can have a wrong value if
  a tmp table was used.
mysql-test/t/user_var.test:
  Extended the test case for bug#18681: User defined variable can have a wrong value if
  a tmp table was used.

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


sql/item_cmpfunc.cc:
  Auto merged

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.


sql/field.h:
  Bug#14171: Wrong internal default value for a BINARY field.
  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.
mysql-test/r/type_binary.result:
  Added a test case for the bug#14171: Wrong internal default value for a BINARY field.
mysql-test/t/type_binary.test:
  Added a test case for the bug#14171: Wrong internal default value for a BINARY field.

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

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


sql/item_cmpfunc.cc:
  Auto merged
sql/item_cmpfunc.h:
  Auto merged
sql/sql_lex.cc:
  Auto merged

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


mysys/mf_iocache.c:
  Auto merged
mysys/my_seek.c:
  Auto merged