- 21 May, 2007 2 commits
-
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/27984/my51-27984
-
holyfoot/hf@mysql.com/hfmain.(none) authored
decimal_round failed to perform a correct rounding of a decimal number if its first nine digits were '9'. It just sets those digits to 0.
-
- 16 May, 2007 4 commits
-
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/8663/my51-8663
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/8663/my51-8663
-
gluh@mysql.com/eagle.(none) authored
-
holyfoot/hf@mysql.com/hfmain.(none) authored
in the case of the overflow in the decimal->integer conversion we didn't return the proper boundary value, but just the result of the conversion we calculated on the moment of the error
-
- 15 May, 2007 1 commit
-
-
gluh@mysql.com/eagle.(none) authored
-
- 12 May, 2007 5 commits
-
-
ibabaev@bk-internal.mysql.com authored
into bk-internal.mysql.com:/data0/bk/mysql-5.1-opt
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.1-opt
-
igor@olga.mysql.com authored
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.1-opt
-
igor@olga.mysql.com authored
a crash when the left operand of the predicate is evaluated to NULL. It happens when the rows from the inner tables (tables from the subquery) are accessed by index methods with key values obtained by evaluation of the left operand of the subquery predicate. When this predicate is evaluated to NULL an alternative access with full table scan is used to check whether the result set returned by the subquery is empty or not. The crash was due to the fact the info about the access methods used for regular key values was not properly restored after a switch back from the full scan access method had occurred. The patch restores this info properly. The same problem existed for queries with IN subquery predicates if they were used not at the top level of the queries.
-
- 11 May, 2007 20 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/27878-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
Corrected test case for the bug#27878.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/27957/my51-27957
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/27957/my50-27957
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/27878-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
database. If a user has a right to update anything in the current database then the access was granted and further checks of access rights for underlying tables wasn't done correctly. The check is done before a view is opened and thus no check of access rights for underlying tables can be carried out. This allows a user to update through a view a table from another database for which he hasn't enough rights. Now the mysql_update() and the mysql_test_update() functions are forces re-checking of access rights after a view is opened.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/27957/my51-27957
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/27957/my51-27957
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/27957/my51-27957
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/27957/my51-27957
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/27957/my50-27957
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/27957/my51-27957
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/27957/my51-27957
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/27957/my50-27957
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/27957/my51-27957
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/27921/my51-27921
-
- 10 May, 2007 8 commits
-
-
gshchepa/uchum@gleb.loc authored
Bug occurs in INSERT IGNORE ... SELECT ... ON DUPLICATE KEY UPDATE statements, when SELECT returns duplicated values and UPDATE clause tries to assign NULL values to NOT NULL fields. NOTE: By current design MySQL server treats INSERT IGNORE ... ON DUPLICATE statements as INSERT ... ON DUPLICATE with update of duplicated records, but MySQL manual lacks this information. After this fix such behaviour becomes legalized. The write_record() function was returning error values even within INSERT IGNORE, because ignore_errors parameter of the fill_record_n_invoke_before_triggers() function call was always set to FALSE. FALSE is replaced by info->ignore.
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.1-single-user
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
igor@olga.mysql.com authored
ref access to a less expensive range access. This occurred only with InnoDB tables.
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-4.1-ndb
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/28005/my51-28005
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.1-single-user
-