- 11 Jul, 2006 1 commit
-
-
evgen@moonbone.local authored
into moonbone.local:/home/evgen/bk-trees/mysql-4.1-opt
-
- 10 Jul, 2006 2 commits
-
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/B14553-4.1-opt
-
To make MySQL compatible with some ODBC applications, you can find the AUTO_INCREMENT value for the last inserted row with the following query: SELECT * FROM tbl_name WHERE auto_col IS NULL. This is done with a special code that replaces 'auto_col IS NULL' with 'auto_col = LAST_INSERT_ID'. However this also resets the LAST_INSERT_ID to 0 as it uses it for a flag so as to ensure that only the first SELECT ... WHERE auto_col IS NULL after an INSERT has this special behaviour. In order to avoid resetting the LAST_INSERT_ID a special flag is introduced in the THD class. This flag is used to restrict the second and subsequent SELECTs instead of LAST_INSERT_ID.
-
- 06 Jul, 2006 2 commits
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-4.1-opt
-
igor@olga.mysql.com authored
The implementation of the method Item_func_reverse::val_str for the REVERSE function modified the argument of the function. This led to wrong results for expressions that contained REVERSE(ref) if ref occurred somewhere else in the expressions.
-
- 05 Jul, 2006 1 commit
-
-
joerg@mysql.com authored
into mysql.com:/M41/bug20216-4.1
-
- 04 Jul, 2006 2 commits
-
-
bar@mysql.com authored
(implemented by by Josh Chamas)
-
sergefp@mysql.com authored
-
- 30 Jun, 2006 14 commits
-
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-4.1-bug16168-push
-
monty@mysql.com authored
into mysql.com:/home/my/mysql-4.1
-
monty@mysql.com authored
into mysql.com:/home/my/mysql-4.1
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-4.1-main
-
monty@mysql.com authored
into mysql.com:/home/my/mysql-4.1
-
monty@mysql.com authored
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-4.1-main
-
tomas@poseidon.ndb.mysql.com authored
- added missing retrieval of hidden primary key
-
kroki@mysql.com authored
into mysql.com:/home/tomash/src/mysql_ab/mysql-4.1-bug20152
-
kroki@mysql.com authored
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.
-
sergefp@mysql.com authored
- Added comments. - Make SEL_ARG::clone() set SEL_ARG::elements in the created copy.
-
monty@mysql.com authored
into mysql.com:/home/my/mysql-4.1
-
monty@mysql.com authored
into mysql.com:/home/my/mysql-4.1
-
monty@mysql.com authored
-
- 29 Jun, 2006 9 commits
-
-
monty@mysql.com authored
into mysql.com:/home/my/mysql-4.1
-
evgen@sunlight.local authored
into sunlight.local:/local_work/autopush/merge-4.1
-
monty@mysql.com authored
hp_test2 now works again Fixed wrong cast, which caused problems with gcc 4.0 and floats in prepared statements (Bug #19694)
-
iggy@mysql.com authored
into mysql.com:/mnt/storeage/mysql-4.1_bug19298
-
evgen@moonbone.local authored
into moonbone.local:/work/merge-4.1
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-4.1-main
-
tomas@poseidon.ndb.mysql.com authored
-
stewart@mysql.com authored
into mysql.com:/home/stewart/Documents/MySQL/4.1/main
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/4.1/warnings
-
- 28 Jun, 2006 3 commits
-
-
gkodinov@mysql.com authored
-
stewart@mysql.com authored
into mysql.com:/home/stewart/Documents/MySQL/4.1/merge
-
stewart@mysql.com authored
change default minimum to 3 bug is *very* timing dependent, unable to reproduce here, but theoretically possible.
-
- 27 Jun, 2006 6 commits
-
-
iggy@mysql.com authored
-
svoj@may.pils.ru authored
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.
-
joerg@mysql.com authored
manual merge from 4.0.
-
joerg@mysql.com authored
-
gkodinov@mysql.com authored
into mysql.com:/home/kgeorge/mysql/4.1/B16458
-
kroki@mysql.com authored
Dec. 31st, 9999 is still a valid date, only starting with Jan 1st 10000 things become invalid (Bug #12356)
-