1003: Incorrect table name
in multi-table DELETE the set of tables to delete from actually 
references then tables in the other list, e.g:
DELETE alias_of_t1 FROM t1 alias_of_t1 WHERE ....
is a valid statement.
So we must turn off table name syntactical validity check for alias_of_t1 
because it's not a table name (even if it looks like one).
In order to do that we add a special flag (TL_OPTION_ALIAS) to 
disable the name checking for the aliases in multi-table DELETE.

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

 Must not use Item_direct_ref in HAVING because it points to
 the new value (witch is not yet calculated for the first row).

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.                                                    
                                                       

myisam/mi_uniue.c:mi_check_unique() should skip trailing spaces comparing 
TEXT and VARTTEXT key segments.

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

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.

into  mysql.com:/usr/home/bar/mysql-4.1.b19741

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

 - Backport patch from 5.0

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

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  zippy.cornsilk.net:/home/cmiller/work/mysql/m41-maint--07OBQ

set.

(Ramil's patch, recreated.)

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/mysql-4.1-maint_bug20721

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

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

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

into  mysql.com:/home/hf/work/mysql-4.1.20317

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

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge

into  anubis.greendragongames.com:/home/greenman/workspace-mysql/mysql/pending/bug-4.1-19364

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge

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

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

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

 - Init start_lineno to 0

into  mysql.com:/Users/kent/mysql/bk/mysql-4.1

  Corrected typo

into  mysql.com:/Users/kent/mysql/bk/mysql-4.1

  Man page for mysqld command move to section 8 (bug#21220)

  Man page for "mysqld" command move to section 8 (bug#21220)

  Man page for "mysqld" command move to section 8 (bug#21220)

into  rakia.(none):/home/kgeorge/mysql/autopush/B20792-4.1-opt

into  rakia.(none):/home/kgeorge/mysql/autopush/B20792-4.1-opt

When processing aggregate functions all tables values are reset
to NULLs at the end of each group. 
When doing that if there are no rows found for a group
the const tables must not be reset as they are not recalculated 
by do_select()/sub_select() for each group.

into  rakia.(none):/home/kgeorge/mysql/autopush/B21019-4.1-opt