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

into  xiphis.org:/home/antony/work2/mysql-5.0-engines-merge

into  xiphis.org:/home/antony/work2/p1-bug10952.1

  "alter table from MyISAM to MERGE lost data without errors and warnings"
  Add new handlerton flag which prevent user from altering table storage
  engine to storage engines which would lose data. Both 'blackhole' and 
  'merge' are marked with the new flag.
  Tests included.

When converting DISTINCT to GROUP BY where the columns are from the covering
index and they are quoted twice in the SELECT list the optimizer is creating
improper processing sequence. This is because of the fact that the columns
of the covering index are not recognized as such and treated as non-index
columns.

Generally speaking duplicate columns can safely be removed from the GROUP
BY/DISTINCT list because this will not add or remove new rows in the
resulting set. Duplicates can be removed even if they are not consecutive
(as is the case for ORDER BY, where the duplicate columns can be removed
only if they are consecutive).

So we can safely transform "SELECT DISTINCT a,a FROM ... ORDER BY a" to
"SELECT a,a FROM ... GROUP BY a ORDER BY a" instead of 
"SELECT a,a FROM .. GROUP BY a,a ORDER BY a". We can even transform 
"SELECT DISTINCT a,b,a FROM ... ORDER BY a,b" to
"SELECT a,b,a FROM ... GROUP BY a,b ORDER BY a,b".

The fix to this bug consists of checking for duplicate columns in the SELECT
list when constructing the GROUP BY list in transforming DISTINCT to GROUP
BY and skipping the ones that are already in.

into  mysql.com:/home/marty/MySQL/mysql-5.0

into  mysql.com:/home/marty/MySQL/mysql-5.0

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

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

No commit message

into mysql.com:/Users/kent/mysql/bk/mysql-5.0-new

Add function 'vio_end' that will cleanup resources allocated by vio and the components it uses.

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

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

save global server variables before fiddling with them and restore them later

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

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

into  rurik.mysql.com:/home/igor/mysql-4.1

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0-bug19136

recalculating results

find_best() call best_access_path().

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0-bug19136

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/FIXES/4.1-bug19136_unass_user_var

A query with a group by and having clauses could return a wrong
result set if the having condition contained a constant conjunct 
evaluated to FALSE.
It happened because the pushdown condition for table with
grouping columns lost its constant conjuncts.
Pushdown conditions are always built by the function make_cond_for_table
that ignores constant conjuncts. This is apparently not correct when
constant false conjuncts are present.