We use the condition from CHECK OPTION twice handling UPDATE command.
First we construnct 'update_cond' AND 'option_cond'
condition to select records to be updated, then we check the
'option_cond' for the updated row.
The problem is that first 'AND' condition is optimized during the 'select'
which can break 'option_cond' structure, so it will be unusable for
the sectond use - to check the updated row.
Possible soultion is either use copy of the condition in the first
use or to make optimization less traumatic for the operands.
I picked the first one. 

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-4.1-opt

containing a select statement that uses an aggregating IN subquery.
Added a parameter to the function fix_prepare_information 
to restore correctly the having clause for the second execution.
Saved andor structure of the having conditions at the proper moment
before any calls of split_sum_func2 that could modify the having structure
adding new Item_ref objects. (These additions, are produced not with 
the statement mem_root, but rather with the execution mem_root.)

into  shellback.(none):/home/msvensson/mysql/mysql-5.0-maint

into  macbook.gmz:/Users/kgeorge/mysql/work/B21180-4.1-opt

into  shellback.(none):/home/msvensson/mysql/mysql-5.0-maint

into  shellback.(none):/home/msvensson/mysql/mysql-5.0-maint

into  shellback.(none):/home/msvensson/mysql/work/my50-work

into  shellback.(none):/home/msvensson/mysql/work/my50-work

into  shellback.(none):/home/msvensson/mysql/mysql-5.0-maint

into  shellback.(none):/home/msvensson/mysql/work/my50-work

into  shellback.(none):/home/msvensson/mysql/mysql-5.0-maint

into  shellback.(none):/home/msvensson/mysql/work/my50-work

into  shellback.(none):/home/msvensson/mysql/mysql-5.0-maint

into  mysql.com:/home/hartmut/projects/mysql/dev/teamtrees/mysql-5.0-maint

into  shellback.(none):/home/msvensson/mysql/mysql-5.0-maint

into  shellback.(none):/home/msvensson/mysql/mysql-5.0-maint

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint

into  shellback.(none):/home/msvensson/mysql/mysql-5.0-maint

into  shellback.(none):/home/msvensson/mysql/mysql-5.0-maint

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt

into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-4.1-opt

into  shellback.(none):/home/msvensson/mysql/mysql-5.0-maint

into  ted.mysql.internal:/home/ted/src/mysql/mysql-5.0-5.1-gca

Bug#21011 The [client] group header was overwritten by "password" option in upgrade_defaults file which confused mysqlcheck thus used to prevent the whole thing from running correctly when the "--password=" option is specified on mysql_upgrade command line with no corresponding "--user=" option

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/mysql-5.0-maint

Bug#21424 mysqldump failing to export/import views.                                                                                                                                                                  

Dumps are created for the tables in each specified database then for the views in each specified database. This bug occurs when any database's views depend on the mysql database's table data while being restored. 
Added command line option --flush-privileges to the mysqldump utility which causes a FLUSH PRIVILIGES statement to be written to the dump after the mysql database.

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/mysql-5.0-maint

into  moonbone.local:/work/21677-bug-4.1-opt-mysql