into  mysql.com:/misc/mysql/32770/50-32770

into  mysql.com:/misc/mysql/31752_/50-31752_

into  mysql.com:/misc/mysql/31752_/50-31752_

fix test program

into  mysql.com:/misc/mysql/32770/50-32770

into  mysql.com:/misc/mysql/31752_/50-31752_

into  mysql.com:/misc/mysql/31752_/50-31752_

into  mysql.com:/misc/mysql/32770/50-32770

into  linux-st28.site:/home/martin/mysql/src/bug32798-united/my50-bug32798-united-push

into  linux-st28.site:/home/martin/mysql/src/bug32858/my50-bug32858-push

into  linux-st28.site:/home/martin/mysql/src/bug32798-united/my50-bug32798-united-push

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

In a union without braces, the order by at the end is applied to the 
overall union. It therefore should not interfere with the individual
select parts of the union.

Fixed by changing our parser rules appropriately.

with null values

For queries containing GROUP_CONCAT(DISTINCT fields ORDER BY fields), there 
was a limitation that the DISTINCT fields had to be the same as ORDER BY 
fields, owing to the fact that one single sorted tree was used for keeping 
track of tuples, ordering and uniqueness. Fixed by introducing a second 
structure to handle uniqueness so that the original structure has only to 
order the result.

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

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

into  mysql.com:/home/psergey/mysql-5.0-bug32198

- Make conditions like "date_col $CMP$ 'datetime-const'" range-sargable

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

subselects into account

It is forbidden to use the SELECT INTO construction inside UNION statements
unless on the last SELECT of the union. The parser records whether it 
has seen INTO or not when parsing a UNION statement. But if the INTO was
legally used in an outer query, an error is thrown if UNION is seen in a
subquery. Fixed in 5.0 by remembering the nesting level of INTO tokens and 
mitigate the error unless it collides with the UNION.

Fixed case of comment.

into  stella.local:/home2/mydev/mysql-5.0-axmrg

into  stella.local:/home2/mydev/mysql-5.0-axmrg

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build

LAST_DAY() says it returns a DATE, not a DATETIME, but didn't zero the time fields.
Adapted from a patch kindly supplied by Claudio Cherubino.

with a fix for bug 32694. 

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

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

  
The problem was that when convert_constant_item is called for subqueries,
this happens when we already started executing the top-level query, and
the field argument of convert_constant_item pointed to a valid table row.
In turn convert_constant_item used the field buffer to compute the value
of its item argument. This copied the item's value into the field,
and made equalities with outer references always true.
  
The fix saves/restores the original field's value when it belongs to an
outer table.

Both arguments of the function NAME_CONST must be constant expressions.
This constraint is checked in the Item_name_const::fix_fields method. 
Yet if the argument of the function was not a constant expression no
error message was reported. As a result the client hanged waiting for a
response.
Now the function Item_name_const::fix_fields reports an error message
when any of the additional context conditions imposed on the function
NAME_CONST is not satisfied. 

The index (key_part_1, key_part-2) was erroneously considered as compatible
with the required ordering in the function test_test_if_order_by_key when 
a query with an ORDER BY clause contained a condition of the form
  key_part_1=const OR key_part_1 IS NULL 
and the order list contained only key_part_2. This happened because the value
of the const_key_parts field in the KEYUSE structure was not formed correctly
for the keys that could be used for ref_or_null access. 
This was fixed in the code of the update_ref_and_keys function.
The problem could not manifest itself for MyISAM databases because the
implementation of the keys_to_use_for_scanning() handler function always
returns an empty bitmap for the MyISAM engine.

into  trift2.:/MySQL/M50/push-5.0