- 26 Jul, 2007 8 commits
-
-
joerg@debian.(none) authored
into debian.(none):/M50/push-5.0
-
joerg@debian.(none) authored
For more information, see WL#3866 and the bugs numbered 28685 and 20390.
-
joerg@debian.(none) authored
into debian.(none):/M50/push-5.0
-
joerg@debian.(none) authored
into debian.(none):/M50/push-5.0
-
joerg@debian.(none) authored
into debian.(none):/M50/push-5.0
-
joerg@debian.(none) authored
into debian.(none):/M41/push-4.1
-
joerg@debian.(none) authored
into debian.(none):/M50/bug16635-5.0
-
joerg@debian.(none) authored
to 150 or 107 characters for those messages which are generated by the embedded server during release builds. This fixes bug#16635: Error messages wrong: absolute path names, "%s" format code See the bug report or the changelog for "sql/share/english/errmsg.txt" for instructions how to do that with other languages, even at the customer site, and for the restrictions to keep.
-
- 25 Jul, 2007 3 commits
-
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
omer@linux.site authored
Note datadict files do not include wrong is_updatable wrong value as a result of bug 30020.
-
- 24 Jul, 2007 2 commits
-
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
-
evgen@moonbone.local authored
When the SQL_BIG_RESULT flag is specified SELECT should store items from the select list in the filesort data and use them when sending to a client. The get_addon_fields function is responsible for creating necessary structures for that. But this function was allowed to do so only for SELECT and INSERT .. SELECT queries. This makes the SQL_BIG_RESULT useless for the CREATE .. SELECT queries. Now the get_addon_fields allows storing select list items in the filesort data for the CREATE .. SELECT queries.
-
- 23 Jul, 2007 4 commits
-
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B29644-5.0-opt
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
gkodinov/kgeorge@magare.gmz authored
Limit the fix for bug 28591 to InnoDB only
-
igor@olga.mysql.com authored
If a primary key is defined over column c of enum type then the EXPLAIN command for a look-up query of the form SELECT * FROM t WHERE c=0 said that the query was with an impossible where condition though the query correctly returned non-empty result set when the table indeed contained rows with error empty strings for column c. This kind of misbehavior was due to a bug in the function Field_enum::store(longlong,bool) that erroneously returned 1 if the the value to be stored was equal to 0. Note that the method Field_enum::store(const char *from,uint length,CHARSET_INFO *cs) correctly returned 0 if a value of the error empty string was stored.
-
- 22 Jul, 2007 4 commits
-
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B28951-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/29494/my41-29494
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/29494/my50-29494
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/29494/my50-29494
-
- 21 Jul, 2007 9 commits
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
gshchepa/uchum@gleb.loc authored
Additional test case fix for bug #29338.
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug29911
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug29911
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
-
igor@olga.mysql.com authored
This bug manifested itself for join queries with GROUP BY and HAVING clauses whose SELECT lists contained DISTINCT. It occurred when the optimizer could deduce that the result set would have not more than one row. The bug could lead to wrong result sets for queries of this type because HAVING conditions were erroneously ignored in some cases in the function remove_duplicates.
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
- 20 Jul, 2007 9 commits
-
-
kent@kent-amd64.(none) authored
into mysql.com:/home/kent/bk/tmp3/mysql-5.0-build
-
gshchepa/uchum@gleb.loc authored
After dumping triggers mysqldump copied the value of the OLD_SQL_MODE variable to the SQL_MODE variable. If the --compact option of the mysqldump was not set the OLD_SQL_MODE variable had the value of the uninitialized SQL_MODE variable. So usually the NO_AUTO_VALUE_ON_ZERO option of the SQL_MODE variable was discarded. This fix is for non-"--compact" mode of the mysqldump, because mysqldump --compact never set SQL_MODE to the value of NO_AUTO_VALUE_ON_ZERO. The dump_triggers_for_table function has been modified to restore previous value of the SQL_MODE variable after dumping triggers using the SAVE_SQL_MODE temporary variable.
-
gkodinov/kgeorge@magare.gmz authored
ORDER BY primary_key on InnoDB table Queries that use an InnoDB secondary index to retrieve data don't need to sort in case of ORDER BY primary key if the secondary index is compared to constant(s). They can also skip sorting if ORDER BY contains both the the secondary key parts and the primary key parts (in that order). This is because InnoDB returns the rows in order of the primary key for rows with the same values of the secondary key columns. Fixed by preventing temp table sort for the qualifying queries.
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/29898-bug-5.0-opt-mysql
-
kostja@bodhi.(none) authored
-
joerg@trift-lap.none authored
into trift-lap.none:/MySQL/M50/push-5.0
-
gkodinov/kgeorge@magare.gmz authored
by long running transaction On Windows opened files can't be deleted. There was a special upgraded lock mode (TL_WRITE instead of TL_WRITE_ALLOW_READ) in ALTER TABLE to make sure nobody has the table opened when deleting the old table in ALTER TABLE. This special mode was causing ALTER TABLE to hang waiting on a lock inside InnoDB. This special lock is no longer necessary as the server is closing the tables it needs to delete in ALTER TABLE. Fixed by removing the special lock. Note that this also reverses the fix for bug 17264 that deals with another consequence of this special lock mode being used.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
unpack_fields() didn't expect NULL_LENGHT in the field's descriptions. In this case we get NULL in the resulting string so cannot use strdup_root to make a copy of it. strdup_root changed with strmake_root as it's NULL-safe
-
df@pippilotta.erinye.com authored
into pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build
-
- 19 Jul, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-