- 06 Apr, 2006 24 commits
-
-
konstantin@mysql.com authored
argument can be either "pedantic" or "old" (actually, or anything else). In case of "pedantic" mode, use -ansi -pedantic compilation flags. Fix the build to compile in pedantic mode. (Version 3 of the patch, with after-review fixes)
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-5.1-bug18558-pnd
-
sergefp@mysql.com authored
* Produce right results for conditions that were transformed to "(partitioning_range) AND (list_of_subpartitioning_ranges)": make each partition id set iterator auto-reset itself after it has returned all partition ids in the sequence * Fix "Range mapping" and "Range mapping" partitioning interval analysis functions to correctly deal with NULL values.
-
svoj@april.(none) authored
into april.(none):/home/svoj/devel/mysql/BUG14945/mysql-5.1-new
-
bar@mysql.com authored
into mysql.com:/usr/home/bar/mysql-5.1-new
-
svoj@april.(none) authored
into april.(none):/home/svoj/devel/mysql/BUG14945/mysql-5.0
-
svoj@april.(none) authored
counter". When TRUNCATE TABLE was called within an stored procedure the auto_increment counter was not reset to 0 even if straight TRUNCATE for this table did this. This fix makes TRUNCATE in stored procedures to be handled exactly in the same way as straight TRUNCATE. We achieve this by rolling back the fix for bug 8850, which is no longer needed since stored procedures don't require prelocked mode anymore (and TRUNCATE is not allowed in stored functions or triggers).
-
msvensson@shellback.(none) authored
into shellback.(none):/home/msvensson/mysql/mysql-5.1
-
msvensson@shellback.(none) authored
into shellback.(none):/home/msvensson/mysql/mysql-5.0
-
bar@mysql.com authored
into mysql.com:/usr/home/bar/mysql-5.1-new
-
bar@mysql.com authored
as it is now required by mysql_set_character_set()
-
bar@mysql.com authored
into mysql.com:/usr/home/bar/mysql-5.1-new
-
bar@mysql.com authored
Bug#18830 incompatibility new libraries with old server Additional 5.0 fix: applying the same patch to client.c.
-
bar@mysql.com authored
into mysql.com:/usr/home/bar/mysql-5.0
-
stewart@mysql.com authored
into mysql.com:/home/stewart/Documents/MySQL/5.1/new-bug18831
-
stewart@mysql.com authored
don't know why this didn't generate a warning, but let's fix it too.
-
stewart@mysql.com authored
-
bar@mysql.com authored
into mysql.com:/usr/home/bar/mysql-5.1-new
-
bar@mysql.com authored
Bug#18830: incompatibility new libraries with old server Don't execute SET NAMES with pre-4.1 server.
-
bar@mysql.com authored
into mysql.com:/usr/home/bar/mysql-5.0
-
bar@mysql.com authored
Adding test case to cover queries which worked incorrectly earlier: Bug#18321: Can't store EuroSign with latin1_german1_ci and latin1_general_ci
-
bar@mysql.com authored
Using local.
-
bar@mysql.com authored
into mysql.com:/usr/home/bar/mysql-5.0
-
bar@mysql.com authored
Backporting a 5.0 change: MAX_BUF was too small for Index.xml Changeing MAX_BUF and adding assert to easier catch the same problem in the future. ctype-extra.c: Regenerating ctype-extra.c with the fixed conf_to_src.
-
- 05 Apr, 2006 16 commits
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/dev/mysql-5.0-0
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/dev/mysql-5.1-0
-
bar@mysql.com authored
into mysql.com:/usr/home/bar/mysql-5.1-new
-
evgen@sunlight.local authored
-
bar@mysql.com authored
Recreating ctype-extra.c with additional 5.1 charset, and with additional missing 5.0 charset due to bug with too small buffer MAX_BUF.
-
bar@mysql.com authored
into mysql.com:/usr/home/bar/mysql-5.1-new
-
bar@mysql.com authored
Buffer was too small to load Index.xml. So some charsets were not gerenrated. Making the buffer bigger, and adding an DBUG_ASSERT, to easier catch the problem in the future. ctype-extra.c: Additional charsets were generated.
-
bar@mysql.com authored
into mysql.com:/usr/home/bar/mysql-5.1-new
-
konstantin@mysql.com authored
never defined. It was used at some point to add -Wuninitialized to debug flags, but not any more. If there is still need to add -Wunitialized, it can be added directly to $global_warnings.
-
mats@mysql.com authored
into mysql.com:/home/bk/b18436-mysql-5.1-new
-
mats@mysql.com authored
into mysql.com:/home/bk/b18436-mysql-5.1-new
-
konstantin@mysql.com authored
-
kent@mysql.com authored
After merge correction
-
mats@mysql.com authored
into mysql.com:/home/bk/b18436-mysql-5.1-new
-
evgen@sunlight.local authored
into sunlight.local:/local_work/16281-bug-5.0-mysql
-
evgen@sunlight.local authored
Mutli-table uses temporary table to store new values for fields. With the new values the rowid of the record to be updated is stored in a Field_string field. Table to be updated is set as source table of the rowid field. But when the temporary table creates the tmp field for the rowid field it converts it to a varstring field because the table to be updated was created by the v4.1. Due to this the stored rowids were broken and no records for update were found. The flag can_alter_field_type is added to Field_string class. When it is set to 0 the field won't be converted to varstring. The Field_string::type() function now always returns MYSQL_TYPE_STRING if can_alter_field_type is set to 0. The multi_update::initialize_tables() function now sets can_alter_field_type flag to 0 for the rowid fields denying conversion of the field to a varstring field.
-