| Bug #33550 | mysqldump 4.0 compatibility broken | ||
|---|---|---|---|
| Submitted: | 28 Dec 2007 10:24 | Modified: | 18 Mar 2009 14:28 |
| Reporter: | Domas Mituzas | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: mysqldump Command-line Client | Severity: | S2 (Serious) |
| Version: | 5.1-bk, 5.0-bk | OS: | Any |
| Assigned to: | Tatiana Azundris Nuernberg | CPU Architecture: | Any |
| Tags: | Contribution, mysqldump | ||
[28 Dec 2007 10:26]
Valeriy Kravchuk
Workaround is to comment out these setting manually/with other command line tools :)
[18 Jul 2008 10:12]
Stefan Meier
The workaround does not work properly if you have some non-ascii characters in your table definition, as the create table statement is always utf8 encoded, so:
If your table definition goes like this:
create table dummy (
germannonascichars varchar(20) default "äöüß"
);
the default value will be someting like 'äüößßÄÖÜ', even if you explicitly specify the charset like
mysqldump --default-character-set=latin1
It would be nice to have an option that turns off the automatic conversion of table definitions to utf8.
[27 Oct 2008 19:08]
Max Bowsher
For clarity's sake it would be nice if these lines were omitted entirely when the prevailing character_set_client for the entire dump is utf8 already.
[12 Jan 2009 16:06]
Robert Heinzmann
diff for Bug 33550 against 5.0.67
Attachment: mysql_dumpfix4_33550.diff (application/octet-stream, text), 48.13 KiB.
[12 Jan 2009 16:07]
Robert Heinzmann
This is a non official patch using version-conditional execution. Warning: This is no offical MySQL Patch.
[23 Jan 2009 18:42]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/63926 2728 Tatiana A. Nurnberg 2009-01-23 Bug#33550: mysqldump 4.0 compatibility broken mysqldump included character_set_client magic that is unknown before 4.1 even when asked for an appropriate compatibility mode. patch changes mysqldump so that the offending statements live in a version-conditional. --compatible=mysql40 is still necessary because we need to ask mysqld to dump in the right format.
[2 Feb 2009 17:28]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/64904 2728 Tatiana A. Nurnberg 2009-02-02 Bug#33550: mysqldump 4.0 compatibility broken mysqldump included character_set_client magic that is unknown before 4.1 even when asked for an appropriate compatibility mode. In compatibility (3.23, 4.0) mode, we do not output charset statements (not even in a "comment conditional"), nor do we do magic on the server, even if the server is sufficient new (4.1+). Table-names will be output converted to the charset requested by mysqldump; if such a conversion is not possible (Ivrit -> Latin), mysqldump will fail.
[24 Feb 2009 7:39]
Tatiana Azundris Nuernberg
patch queued for 5.0.79, 5.1.33, 6.0.10 in -bugteam
[9 Mar 2009 14:13]
Bugs System
Pushed into 5.0.79 (revid:joro@sun.com-20090309135922-a0di9ebkxoj4d4wv) (version source revid:aelkin@mysql.com-20090224143545-7xc77386o8mg623c) (merge vers: 5.0.79) (pib:6)
[13 Mar 2009 1:52]
Paul DuBois
Noted in 5.0.79 changelog. mysqldump --compatible=mysql40 emitted statements referring to the character_set_client system variable, which is unknown before MySQL 4.1. Now the statements are enclosed in version-specific comments. Setting report to NDI pending push into 5.1.x/6.0.x
[13 Mar 2009 19:03]
Bugs System
Pushed into 5.1.33 (revid:joro@sun.com-20090313111355-7bsi1hgkvrg8pdds) (version source revid:azundris@mysql.com-20090219172228-jj3zrpk2weqo2har) (merge vers: 5.1.33) (pib:6)
[13 Mar 2009 20:28]
Paul DuBois
Noted in 5.1.33 changelog. Setting report to NDI pending push into 6.0.x.
[18 Mar 2009 13:19]
Bugs System
Pushed into 6.0.11-alpha (revid:joro@sun.com-20090318122208-1b5kvg6zeb4hxwp9) (version source revid:azundris@mysql.com-20090219173609-tbjx1l3aq6axz9tg) (merge vers: 6.0.10-alpha) (pib:6)
[18 Mar 2009 14:28]
Paul DuBois
Noted in 6.0.11 changelog.
[9 May 2009 16:42]
Bugs System
Pushed into 5.1.34-ndb-6.2.18 (revid:jonas@mysql.com-20090508185236-p9b3as7qyauybefl) (version source revid:jonas@mysql.com-20090508100057-30ote4xggi4nq14v) (merge vers: 5.1.33-ndb-6.2.18) (pib:6)
[9 May 2009 17:39]
Bugs System
Pushed into 5.1.34-ndb-6.3.25 (revid:jonas@mysql.com-20090509063138-1u3q3v09wnn2txyt) (version source revid:jonas@mysql.com-20090508175813-s6yele2z3oh6o99z) (merge vers: 5.1.33-ndb-6.3.25) (pib:6)
[9 May 2009 18:37]
Bugs System
Pushed into 5.1.34-ndb-7.0.6 (revid:jonas@mysql.com-20090509154927-im9a7g846c6u1hzc) (version source revid:jonas@mysql.com-20090509073226-09bljakh9eppogec) (merge vers: 5.1.33-ndb-7.0.6) (pib:6)
Description: 5.0 and 5.1 mysqldumps fail at --compatible=mysql40, by using these statements: SET @saved_cs_client = @@character_set_client; SET character_set_client = @saved_cs_client; in dump output. Same applies to multiple other compatibility options: How to repeat: $ mysqldump anydatabase: -- -- Table structure for table "inno" -- DROP TABLE IF EXISTS "inno"; SET @saved_cs_client = @@character_set_client; SET character_set_client = utf8; CREATE TABLE "inno" ( "a" int(11) NOT NULL, "b" int(11) default NULL, "c" int(11) default NULL, PRIMARY KEY ("a"), KEY "b" ("b"), KEY "b_2" ("b","c") ); SET character_set_client = @saved_cs_client; Suggested fix: put this into /*! wrappers */