into serg.mylan:/usr/home/serg/Abk/mysql-4.1

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

into mysql.com:/usr/home/bar/mysql-4.1

  latin1_spanish_ci produced unknown collation error.

Integrate suggestions from Tomas Ulin's mail. (r.e. reporting an error in the case of endianness mismatch).

for release debug build please configure with --without-ndb-debug

into sanja.is.com.ua:/home/bell/mysql/bk/work-qc-4.1

into sanja.is.com.ua:/home/bell/mysql/bk/work-global-4.1

into mysql.com:/home/jonas/src/mysql-4.1

into serg.mylan:/usr/home/serg/Abk/mysql-4.1

into mysql.com:/home/jonas/src/mysql-4.1

1 if the return type is int or int_fast8_t.  The test case that showed
this problem is rpl000001 and the tested version was MySQL 5.0.2.  The
compiler with the problem is GCC 3.0.4 runing on "Linux bitch 2.4.18
#2 Thu Apr 11 14:37:17 EDT 2002 sparc64 unknown".

By changing the return type to bool the problem disappear.  (Another
way to make the problem disappear is to simply print the returned
value with printf("%d",?).  The printed returned value is always 0 in
the test cases I have run.)  This is only a partial solution to the
problem, since someone could later change the return type of the
function back to int or some other type that does not work.

into serg.mylan:/usr/home/serg/Abk/mysql-4.1

into mysql.com:/home/jonas/src/mysql-4.1

    Bug #6284 - report truncation warnings in INSERT ... SELECT only for "INSERT" part
sql/sql_insert.cc
    Bug #6284 - report truncation warnings in INSERT ... SELECT only for "INSERT" part

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

into mysql.com:/home/wax/mysql/mysql-4.1testtemp

into mysql.com:/home/jonas/src/mysql-4.1

into mysql.com:/space/bk/b6391-mysql-4.1

  CREATE DATABASE statement used the current database instead of the
  database created when checking conditions for replication.
  CREATE/DROP/ALTER DATABASE statements are now replicated based on
  the manipulated database.

insertion of new records partially failed. It would get logged because of the
logic to log a partially-failed 'INSERT ... SELECT' (which can't be rolled back
in non-transactional tables), but 'CREATE TABLE ... SELECT' is always rolled
back on failure, even for non-transactional tables. (Bug #6682)
(Original fix reimplemented after review by Serg and Guilhem.)

  discovered on Mac OS X