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

now takes mbmaxlen into account when calculating max_length of new field. 

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

 - Backport patch from 5.0

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

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

into  neptunus.(none):/home/msvensson/mysql/mysql-4.1

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

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

           privileges

This problem is 4.1 specific. It doesn't affect 4.0 and was fixed
in 5.x before.

Having any mysql user who is allowed to issue multi table update
statement and any column/table grants, allows this user to update
any table on a server (mysql grant tables are not exception).

check_grant() accepts number of tables (in table list) to be checked
in 5-th param. While checking grants for multi table update, number
of tables must be 1. It must never be 0 (actually we have
DBUG_ASSERT(number > 0) in 5.x in grant_check() function).

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

into  rama.(none):/home/jimw/my/mysql-5.0-16502

into  rama.(none):/home/jimw/my/mysql-5.0-16502

into  rama.(none):/home/jimw/my/mysql-5.0-16502

into  zippy.cornsilk.net:/home/cmiller/work/mysql/m41-maint--07OBQ

into  bodhi.local:/opt/local/work/mysql-5.0-runtime-merge