Corrected test case result after fix for bug#18165
view.result, view.test:
  Corrected test case for bug#21261

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

Made [NOT]BETWEEN predicates SARGable in respect to the second and 
the third arguments.

into  sunlight.local:/local_work/21261-bug-5.0-mysql

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

SELECT right instead of INSERT right was required for an insert into to a view.
This wrong behaviour appeared after the fix for bug #20989. Its intention was
to ask only SELECT right for all tables except the very first for a complex
INSERT query. But that patch has done it in a wrong way and lead to asking 
a wrong access right for an insert into a view.

The setup_tables_and_check_access() function now accepts two want_access
parameters. One will be used for the first table and the second for other
tables.

into  mysql.com:/home/psergey/mysql-5.0-opt-bug21282-r2

In fix for BUG#15872, a condition of type "t.key NOT IN (c1, .... cN)"
where N>1000, was incorrectly converted to
  (-inf < X < c_min) OR (c_max < X)
Now this conversion is removed, we dont produce any range lists for such
conditions.

This bug is a side-effect of bug fix #16377. NOW() is optimized in
BETWEEN to integer constants to speed up query execution. When view is being
created it saves already modified query and thus becomes wrong.

The agg_cmp_type() function now substitutes constant result DATE/TIME functions 
for their results only if the current query isn't CREATE VIEW or SHOW CREATE
VIEW.

BUG#21077: Possible crash caused by invalid sequence of handler::* calls:                                                
The crash was caused by invalid sequence of handler::** calls:                                                           
  ha_smth->index_init();                                                                                                 
  ha_smth->index_next_same(); (2)                                                                                        
(2) is an invalid call as it was not preceeded by any 'scan setup' call
like index_first() or index_read(). The cause was that QUICK_SELECT::reset()
didn't "fully reset" the quick select- current QUICK_RANGE wasn't forgotten,
and quick select might attempt to continue reading the range, which would
result in the above mentioned invalid sequence of handler calls.

5.x versions are not affected by the bug - they already have the missing
"range=NULL" clause.                                                    
                                                       

 - undeterminstic tests fixed

            on a second table in a join
- undeterministic output of the test case removed.

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

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

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

Disable const propagation for Item_hex_string.
This must be done because Item_hex_string->val_int() is not
the same as (Item_hex_string->val_str() in BINARY column)->val_int().
We cannot simply disable the replacement in a particular context (
e.g. <bin_col> = <int_col> AND <bin_col> = <hex_string>) since
Items don't know the context they are in and there are functions like 
IF (<hex_string>, 'yes', 'no').
Note that this will disable some valid cases as well 
(e.g. : <bin_col> = <hex_string> AND <bin_col2> = <bin_col>) but 
there's no way to distinguish the valid cases without having the
Item's parent say something like : Item->set_context(Item::STRING_RESULT)
and have all the Items that contain other Items do that consistently.

             optimizer does not honor IGNORE INDEX
 - Allow an index to be used for sorting the table 
   instead of filesort only if it is not disabled by
   IGNORE INDEX.

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

             table in a join
 The optimizer removes redundant columns in ORDER BY. It is considering 
redundant every reference to const table column, e.g b in :
create table t1 (a int, b int, primary key(a)); 
select 1 from t1 order by b where a = 1

But it must not remove references to const table columns if the 
const table is an outer table because there still can be 2 values :
the const value and NULL. e.g.:
create table t1 (a int, b int, primary key(a));
select t2.b c from t1 left join t1 t2 on (t1.a = t2.a and t2.a = 5) 
  order by c;

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

into  may.pils.ru:/home/svoj/devel/mysql/BUG7391/mysql-5.0

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

into  may.pils.ru:/home/svoj/devel/mysql/BUG20060/mysql-5.0

Problem described in this bug report affects MyISAM tables only.

Running mysqld --flush instructs mysqld to sync all changes to disk
after each SQL statement. It worked well for INSERT and DELETE
statements, but it did sync for UPDATE only in case if there was
index change (change of colum that has an index). If no updated column
has an index, data wasn't synced to disk.

This fix makes UPDATE statement to sync data to disk even if there is
no index change (that is only data change) and mysqld is run with
--flush option.

  After merge fix

into  sunlight.local:/local_work/leak_fix

into  sunlight.local:/local_work/leak_fix

  Correct memory leak fix

  Memory leak fix

into  sunlight.local:/local_work/leak_fix

into  sunlight.local:/local_work/leak_fix

  Memory leak fix