- 01 May, 2007 1 commit
-
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.1-opt
-
- 30 Apr, 2007 4 commits
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
igor@olga.mysql.com authored
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug24856
-
igor@olga.mysql.com authored
-
- 29 Apr, 2007 19 commits
-
-
igor@olga.mysql.com authored
some rollup rows (rows with NULLs for grouping attributes) if GROUP BY list contained constant expressions. This happened because the results of constant expressions were not put in the temporary table used for duplicate elimination. In fact a constant item from the GROUP BY list of a ROLLUP query can be replaced for an Item_null_result object when a rollup row is produced . Now the JOIN::rollup_init function wraps any constant item referenced in the GROYP BY list of a ROLLUP query into an Item_func object of a special class that is never detected as constant item. This ensures creation of fields for such constant items in temporary tables and guarantees right results when the result of the rollup operation first has to be written into a temporary table, e.g. in the cases when duplicate elimination is required.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/16377-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
The test case for the bug#27590 is altered.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.1-opt
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.1-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-4.1-opt
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.1-opt
-
gshchepa/uchum@gshchepa.loc authored
-
gshchepa/uchum@gshchepa.loc authored
into gshchepa.loc:/home/uchum/work/bk-trees/mysql-5.0-opt-13191
-
gshchepa/uchum@gshchepa.loc authored
-
gshchepa/uchum@gshchepa.loc authored
into gshchepa.loc:/home/uchum/work/bk-trees/mysql-5.0-opt-13191
-
gshchepa/uchum@gshchepa.loc authored
into gshchepa.loc:/home/uchum/work/bk-trees/mysql-4.1-opt-13191
-
gshchepa/uchum@gshchepa.loc authored
into gshchepa.loc:/home/uchum/work/bk-trees/mysql-5.0-opt
-
gshchepa/uchum@gshchepa.loc authored
-
- 28 Apr, 2007 3 commits
-
-
gshchepa/uchum@gshchepa.loc authored
INSERT...ON DUPLICATE KEY UPDATE may cause error 1032: "Can't find record in ..." if we are inserting into InnoDB table unique index of partial key with underlying UTF-8 string field. This error occurs because INSERT...ON DUPLICATE uses a wrong procedure to copy string fields of multi-byte character sets for index search.
-
gshchepa/uchum@gshchepa.loc authored
into gshchepa.loc:/home/uchum/work/bk-trees/mysql-5.0-opt
-
gshchepa/uchum@gshchepa.loc authored
This bug occurs when error message length exceeds allowed limit: my_error() function outputs "%s" sequences instead of long string arguments. Formats like %-.64s are very common in errmsg.txt files, however my_error() function simply ignores precision of those formats.
-
- 27 Apr, 2007 13 commits
-
-
evgen@sunlight.local authored
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.1-single-user
-
tomas@whalegate.ndb.mysql.com authored
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/16377-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/27590-bug-5.0-opt-mysql
-
tomas@whalegate.ndb.mysql.com authored
- reverting wrong part in patch
-
tomas@whalegate.ndb.mysql.com authored
-
tomas@whalegate.ndb.mysql.com authored
-
tomas@whalegate.ndb.mysql.com authored
add a new method is_equal in class Field_blob to compare BLOB field when alter table
-
tomas@whalegate.ndb.mysql.com authored
- add additional sleep so that we don't get 100% cpu usage retrying saomething that can take some time before succeeding
-
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
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.1-single-user
-