into  mysql.com:/home/kgeorge/mysql/4.1/warnings

into  mysql.com:/home/kgeorge/mysql/4.1/B16458

'SELECT DISTINCT a,b FROM t1' should not use temp table if there is unique 
index (or primary key) on a.
There are a number of other similar cases that can be calculated without the
use of a temp table : multi-part unique indexes, primary keys or using GROUP BY 
instead of DISTINCT.
When a GROUP BY/DISTINCT clause contains all key parts of a unique
index, then it is guaranteed that the fields of the clause will be
unique, therefore we can optimize away GROUP BY/DISTINCT altogether.
This optimization has two effects:
* there is no need to create a temporary table to compute the
   GROUP/DISTINCT operation (or the temporary table will be smaller if only GROUP 
   is removed and DISTINCT stays or if DISTINCT is removed and GROUP BY stays)
* this causes the statement in effect to become updatable in Connector/Java
because the result set columns will be direct reference to the primary key of 
the table (instead to the temporary table that it currently references). 

Implemented a check that will optimize away GROUP BY/DISTINCT for queries like 
the above.
Currently it will work only for single non-constant table in the FROM clause.

This was another manifestation of the problems fixed in the
patch for bug 16674.
Wrong calculation of length of the search prefix in the pattern
string led here to a wrong result set for a query in 4.1. 
The bug could be demonstrated for any multi-byte character set. 

Server crashed in some cases when a query required a MIN/MAX
agrregation for a 'ucs2' field. 
In these cases  the aggregation caused calls of the function
update_tmptable_sum_func that indirectly invoked 
the method Item_sum_hybrid::min_max_update_str_field() 
containing a call to strip_sp for a ucs2 character set.
The latter led directly to the crash as it used my_isspace
undefined for the ucs2 character set.
Actually the call of strip_sp is not needed at all in this
situation and has been removed by the fix.

execution plans in 4.1 and 5.0.

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

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

This bug in Field_string::cmp resulted in a wrong comparison 
with keys in partial indexes over multi-byte character fields.
Given field a is declared as a varchar(16) collate utf8_unicode_ci
INDEX(a(4)) gives us an example of such an index.
  
Wrong key comparisons could lead to wrong result sets if 
the selected query execution plan used a range scan by 
a partial index over a utf8 character field.
This also caused wrong results in many other cases.

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

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

            functions in queries

Using MAX()/MIN() on table with disabled indexes (by ALTER TABLE)
results in error 124 (wrong index) from storage engine.

The problem was that optimizer use disabled index to optimize
MAX()/MIN(). Normally it must skip disabled index and perform
table scan.

This patch skips disabled indexes for min/max optimization.

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

The length of the prefix of the pattern string in the LIKE predicate that 
determined the index range to be scanned was calculated incorrectly for
multi-byte character sets. 
As a result of this in 4. 1 the the scanned range was wider then necessary
if the prefix contained not only one-byte characters.  
In 5.0 additionally it caused missing some rows from the result set.

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

  Added test case for bug#18759 Incorrect string to numeric conversion.  
select.test:
  Added test case for bug#18759 Incorrect string to numeric conversion.
item_cmpfunc.cc:
  Cleanup after fix for bug#18360 removal

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

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

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

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

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

  Reverted fix for bug#18360

into  mysql.com:/home/kgeorge/mysql/4.1/B9676

              tables
Currently in INSERT ... SELECT ... LIMIT ... the compiler uses a 
temporary table to store the results of SELECT ... LIMIT .. and then
uses that table as a source for INSERT. The problem is that in some cases
it actually skips the LIMIT clause in doing that and materializes the 
whole SELECT result set regardless of the LIMIT.
This fix is limiting the process of filling up the temp table with only 
that much rows that will be actually used by propagating the LIMIT value.

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

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

Certain updates of table joined to self results in unexpected
behavior.

The problem was that record cache was mistakenly enabled for
self-joined table updates. Normally record cache must be disabled
for such updates.

Fixed wrong condition in code that determines whether to use
record cache for self-joined table updates.

Only MyISAM tables were affected.

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

  Avoid error message trying 'windoze-dsp' in obsolete directory
compile-dist:
  Avoid error message for target 'distclean' and no Makefile

  Make output less verbose
  Make temporary directory name unique
  Remove temporary directory on interrupt

  Include "sql_yacc.yy" for completeness (bug#20387)

  Delete: netware/mysql_install.def
Makefile.am:
  Removed obsolete "mysql_install.def"

  Fix for bug#16716 for --ps-protocol mode.
item_cmpfunc.cc:
  Fix for a memory allocation/freeing problem in agg_cmp_type() after fix
for bug#16377. Few language corrections.

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

into moonbone.local:/work/16377-4.1-after

  Post fix for bug#16377