into  mysql.com:/space_old/pekka/ndb/version/my41

  "temporary table with data directory option fails"
  myisam should not use user-specified table name when creating
  temporary tables and use generated connection specific real name.
  Test included.

into mysql.com:/M41/bug20216-4.1

into  clam.ndb.mysql.com:/space/pekka/ndb/version/my41

(implemented by by Josh Chamas)

into  mysql.com:/home/psergey/mysql-4.1-bug16168-push

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

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

into  poseidon.ndb.mysql.com:/home/tomas/mysql-4.1-main

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

into  poseidon.ndb.mysql.com:/home/tomas/mysql-4.1-main

- added missing retrieval of hidden primary key

into  mysql.com:/home/tomash/src/mysql_ab/mysql-4.1-bug20152

When using a parameter bind MYSQL_TYPE_DATE in a prepared statement,
the time part of the MYSQL_TIME buffer was written to zero in
mysql_stmt_execute(). The param_store_date() function in libmysql.c
worked directly on the provided buffer.
Changed to use a copy of the buffer.

 - Added comments.
 - Make SEL_ARG::clone() set SEL_ARG::elements in the created copy.

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

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

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

into sunlight.local:/local_work/autopush/merge-4.1

hp_test2 now works again
Fixed wrong cast, which caused problems with gcc 4.0 and floats in prepared statements (Bug #19694)

into  mysql.com:/mnt/storeage/mysql-4.1_bug19298

into moonbone.local:/work/merge-4.1

into  poseidon.ndb.mysql.com:/home/tomas/mysql-4.1-main

into  mysql.com:/home/stewart/Documents/MySQL/4.1/main

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

into  mysql.com:/home/stewart/Documents/MySQL/4.1/merge

change default minimum to 3

bug is *very* timing dependent, unable to reproduce here, but theoretically possible.

Produce a warning if DATA/INDEX DIRECTORY is specified in
ALTER TABLE statement.

Ignoring of these options is documented in the symbolic links
section of the manual.

manual merge from 4.0.

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

Dec. 31st, 9999 is still a valid date, only starting with Jan 1st 10000 things become invalid (Bug #12356)

'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.

into mysql.com:/home/hf/work/mysql-4.1.clean