- 06 Dec, 2004 6 commits
-
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-4.1
-
tomas@poseidon.ndb.mysql.com authored
-
bar@mysql.com authored
into mysql.com:/usr/home/bar/mysql-4.1
-
bar@mysql.com authored
latin1_spanish_ci produced unknown collation error.
-
stewart@mysql.com[stewart] authored
Integrate suggestions from Tomas Ulin's mail. (r.e. reporting an error in the case of endianness mismatch).
-
stewart@mysql.com[stewart] authored
-
- 04 Dec, 2004 2 commits
-
-
pekka@mysql.com authored
-
lars@mysql.com authored
-
- 03 Dec, 2004 24 commits
-
-
bell@sanja.is.com.ua authored
-
tomas@poseidon.ndb.mysql.com authored
for release debug build please configure with --without-ndb-debug
-
bell@sanja.is.com.ua authored
-
bell@sanja.is.com.ua authored
into sanja.is.com.ua:/home/bell/mysql/bk/work-qc-4.1
-
bell@sanja.is.com.ua authored
into sanja.is.com.ua:/home/bell/mysql/bk/work-global-4.1
-
jimw@mysql.com authored
-
jimw@mysql.com authored
-
joreland@mysql.com authored
into mysql.com:/home/jonas/src/mysql-4.1
-
serg@serg.mylan authored
into serg.mylan:/usr/home/serg/Abk/mysql-4.1
-
joreland@mysql.com authored
into mysql.com:/home/jonas/src/mysql-4.1
-
lars@mysql.com authored
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.
-
serg@serg.mylan authored
into serg.mylan:/usr/home/serg/Abk/mysql-4.1
-
joreland@mysql.com authored
into mysql.com:/home/jonas/src/mysql-4.1
-
serg@serg.mylan authored
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
-
joreland@mysql.com authored
-
pekka@mysql.com authored
into mysql.com:/space/pekka/ndb/version/my41
-
pekka@mysql.com authored
-
wax@mysql.com authored
into mysql.com:/home/wax/mysql/mysql-4.1testtemp
-
wax@kishkin.ru authored
-
joreland@mysql.com authored
into mysql.com:/home/jonas/src/mysql-4.1
-
joreland@mysql.com authored
-
mats@mysql.com authored
into mysql.com:/space/bk/b6391-mysql-4.1
-
mats@mysql.com authored
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.
-
jimw@mysql.com authored
-
- 02 Dec, 2004 8 commits
-
-
jimw@mysql.com authored
-
jimw@mysql.com authored
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.)
-
lenz@mysql.com authored
discovered on Mac OS X
-
serg@serg.mylan authored
-
lenz@mysql.com authored
into mysql.com:/space/my/mysql-4.1
-
joerg@mysql.com authored
-
lenz@mysql.com authored
Engine
-
joerg@mysql.com authored
Change to prevent the failure of "make distclean" on the missing 'regex/Makefile' (and, later, 'strings/Makefile').
-