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

itself when executing queries referring to a view with GROUP BY
an expression containing non-constant interval.
It happened because Item_date_add_interval::eq neglected the
fact that the method can be applied to an expression of the form
    date(col) + interval time_to_sec(col) second
at the time when col could not be evaluated yet.
An attempt to evaluate time_to_sec(col) in this method resulted
in a crash.

  Change mode to -rw-rw-r--

  Change mode to -rw-rw-r--
Ereport.pl, Ecreate.pl, Ecompare.pl:
  Change mode to -rwxrwxr--

  Change mode to -rw-rw-r--
dbug_add_tags.pl:
  Change mode to -rwxrwxr--

into  mysql.com:/home/kgeorge/mysql/5.0/B7549

replaced get_field(MEM_ROOT *mem, Field *field) with 
get_field(MEM_ROOT *mem, Field *field, String *res).
It allows to avoid strlen().

into mysql.com:/home/gluh/MySQL/Merge/5.0

into mysql.com:/home/gluh/MySQL/Merge/5.0

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

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

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

into mysql.com:/home/gluh/MySQL/Merge/5.0

into  mysql.com:/home/mysql-5.0-10418

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

 - Don't kill the active connection to the server, instead read 
   the connection id, switch connection and kill the first one from there.

a worse execution plan than in 4.1 for some queries.
It happened due the fact that at some conditions the 
optimizer always preferred range or full index scan access
methods to lookup access methods even when the latter were much
cheaper. 
The problem was not observed in 4.1 for the reported query
because the WHERE condition was not of a form that could
cause the problem.
Equality propagation introduced on 5.0 added an extra 
predicate and changed the WHERE condition. The new condition
provoked the optimizer to make a bad choice.

The problem was fixed by the patch for bug 17379.

  Stepped up to 4.0.28

into  zippy.(none):/home/cmiller/work/mysql/mysql-5.0-maint

When a view statement is compiled on CREATE VIEW time, most of the 
optimizations should not be done. Finding the right optimization 
for a subquery is one of them.
Unfortunately the optimizer is resolving the column references of 
the left expression of IN subqueries in the process of deciding 
witch optimization to use (if needed). So there should be a 
special case in Item_in_subselect::fix_fields() : check the 
validity of the left expression of IN subqueries in CREATE VIEW 
mode and then proceed as normal. 

into  mysql.com:/home/mysql-4.1-10418

into  mysql.com:/home/mysql-5.0-19263

  Compile in all character sets in Max (bug#14918)

into  production.mysql.com:/usersnfs/rkalimullin/mysql-5.0

into  production.mysql.com:/usersnfs/rkalimullin/mysql-5.0

into  zippy.(none):/home/cmiller/mysql-5.0__bug19564

Re-work best_access_path() and find_best() to reuse E(#rows(range access)) as
E(#rows(ref[_or_null](const) access) only when it is appropriate.
[This is the final cumulative patch]

into  mysql.com:/usr/home/ram/work/mysql-5.0

into  zippy.(none):/home/cmiller/mysql-5.0__bug19564

into  mysql.com:/usr/home/ram/work/4.1.b18501

into  mysql.com:/home/kgeorge/mysql/5.0/B18068

Correct a bug (that I introduced, after using Oracle's database software for 
too many years) where the length of the database-sent data is incorrectly 
used to infer NULLness.

into  mysql.com:/home/psergey/mysql-5.0-best_access_path_j-push

into  mysql.com:/home/psergey/mysql-5.0-best_access_path_j-push