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

into  mysql.com:/home/svoj/devel/mysql/engines/mysql-5.0-engines

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  mysql.com:/home/svoj/devel/mysql/engines/mysql-4.1-engines

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

into  mysql.com:/home/svoj/devel/mysql/engines/mysql-4.1-engines

Backport from 5.1.
Raised STACK_MIN_SIZE for Debian GNU/Linux Sid,
Linux kernel 2.6.16,
gcc version 3.3.6 (Debian 1:3.3.6-13),
libc6-dbg 2.3.6.ds1-4,
Pentium4 (x86),
BUILD/compile-pentium-debug-max
Raised about 100 Bytes above the required minimum.

into  chilla.local:/home/mydev/mysql-5.0-merge

into  chilla.local:/home/mydev/mysql-5.0-merge

into  chilla.local:/home/mydev/mysql-4.1-merge

into  mysql.com:/data0/bk/mysql-5.0-kt

Repair table could crash a server if there is not sufficient
memory (myisam_sort_buffer_size) to operate. Affects not only
repair, but also all statements that use create index by sort:
repair by sort, parallel repair, bulk insert.

Return an error if there is not sufficient memory to store at
least one key per BUFFPEK.

Also fixed memory leak if thr_find_all_keys returns an error.

into  sunlight.local:/local_work/14959-bug-5.0-opt-mysql

  Cleanup of fix for bug#14959.

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

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

into  macbook.gmz:/Users/kgeorge/mysql/work/B21798-5.0-opt-merge

            list using a function
When executing dependent subqueries they are re-inited and re-exec() for 
each row of the outer context.
The cause for the bug is that during subquery reinitialization/re-execution,
the optimizer reallocates JOIN::join_tab, JOIN::table in make_simple_join()
and the local variable in 'sortorder' in create_sort_index(), which is
allocated by make_unireg_sortorder().
Care must be taken not to allocate anything into the thread's memory pool
while re-initializing query plan structures between subquery re-executions.
All such items mush be cached and reused because the thread's memory pool
is freed at the end of the whole query.
Note that they must be cached and reused even for queries that are not 
otherwise cacheable because otherwise it will grow the thread's memory 
pool every time a cacheable query is re-executed. 
We provide additional members to the JOIN structure to store references 
to the items that need to be cached.

into  macbook.gmz:/Users/kgeorge/mysql/work/B22367-5.0-opt-merge

into  chilla.local:/home/mydev/mysql-4.1-bug12240

account predicates that become sargable after reading const tables.
In some cases this resulted in choosing non-optimal execution plans.
Now info of such potentially saragable predicates is saved in
an array and after reading const tables we check whether this
predicates has become saragable.

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

 When using index for group by and range access the server isolates    
 a set of ranges based on the conditions over the key parts of the
 index used. Then it uses only the ranges over the GROUP BY fields to
 jump from one group to another. Since the GROUP BY fields may form a
 prefix over the index, we may use only a prefix of the ranges produced
 by the range optimizer.
 Each range contains a notion on whether it includes its border values.
 The problem is that when using a range prefix, the last range is open
 because it assumes that there is a range on the next keypart. Thus when
 we use a prefix range as it is, it excludes all border values.
 The solution is when ignoring the suffix of the range conditions 
 (to jump over the GROUP BY prefix only) the server must change the 
 remaining intervals so they always contain their borders, e.g. 
 if the whole range was :
 (1,-inf) <= (<group_by_col>,<min_max_arg_col>) < (1, 3) we must make
 (1) <= (<group_by_col>) <= (1) because (a,b) < (c1,c2) means :
 a < c1 OR (a = c1 AND b < c2).

into  chilla.local:/home/mydev/mysql-5.0-bug12240

             strings
MySQL is setting the flag HA_END_SPACE_KEYS for all the keys that reference
text or varchar columns with collation different than binary.
This was done to handle correctly the situation where a lookup on such a key
may return more than 1 row because of the presence of many rows that differ
only by the amount of trailing space in the table's string column.
Inserting such values however appears to violate the unique checks on 
INSERT/UPDATE. Thus that flag must not be set as it will prevent the optimizer
from choosing a faster access method.
This fix removes the setting of the HA_END_SPACE_KEYS flag.

into  macbook.gmz:/Users/kgeorge/mysql/work/B14019-5.0-opt

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

into  chilla.local:/home/mydev/mysql-5.0-bug12240

into  chilla.local:/home/mydev/mysql-4.1-bug12240

into  macbook.gmz:/Users/kgeorge/mysql/work/B14019-5.0-opt

   When resolving unqualified name references MySQL was not
   checking what is the item type for the reference. Thus
   e.g a string literal item that has by convention a name
   equal to its string value will also work as a reference to 
   a SELECT list item or a table field.
   Fixed by allowing only Item_ref or Item_field to referenced by
   (unqualified) name.

The mysql_alter_table() was able to rename only a table.

The view/table renaming code is moved from the function rename_tables 
to the new function called do_rename().
The mysql_alter_table() function calls it when it needs to rename a view.

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug9678

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-real