Bug #12819 mysqldump incorrectly dumps 0x9d
Submitted: 26 Aug 2005 1:24 Modified: 11 Oct 2005 0:51
Reporter: Tim Freeman Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server: Replication Severity:S2 (Serious)
Version:4.1.11a OS:Linux (Linux (Debian Sarge))
Assigned to: Bugs System CPU Architecture:Any

[26 Aug 2005 1:24] Tim Freeman
Description:
If I put the byte 0x9d (which is 157 decimal) in a text field, then write it with mysqldump, then 
read it back, I get 63 decimal.  Here's the terminal dialogue, with some chatter
edited out and one comment added near "<<<".  The only workaround I can see
is to avoid using mysqldump when binary data is present.

How to repeat:
$ mysql -D tim2_db
mysql> show create table foo;
CREATE TABLE `foo` (
  `data` text
) ENGINE=MyISAM DEFAULT CHARSET=latin1
mysql> delete from foo;
mysql> insert into foo (data) values (0x9d);
mysql> select ord(data) from foo;
+-----------+
| ord(data) |
+-----------+
|       157 |
+-----------+
mysql> Bye
$ mysqldump tim2_db foo>tim2.sql
$ mysql -D tim2_db < tim2.sql
$ mysql -D tim2_db
mysql> select ord(data) from foo;
+-----------+
| ord(data) |
+-----------+
|        63 | <<<Should be 157.
+-----------+
[26 Aug 2005 12:40] Hartmut Holzgraefe
works with 5.0.11 but not with 4.1.12

while 0x9d is not really a defined iso-8859-1 character (0x80-0x9F are undefined)
it should still either be properly dumped or trying to insert the character into a
latin1 filed should at least throw a warning ...
[26 Aug 2005 20:32] Tim Freeman
A workaround is to create the table with charset "binary".

This forces a subsequent workaround with our Python DB interface because data from
a table with charset binary comes in as an array instead of a string, but  that's
easier than either reimplementing mysqldump or getting along without it.
[11 Oct 2005 0:51] Patrick Galbraith
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

I have this working just fine in 4.1.15, and suspect it was something that changed in the 
client API, because this is the common denominator (mysqldump gets its values via the API)

radha:~/mysql-build/mysql-4.1/client patg$ ./mysqldump -uroot -S /tmp/mysqld-4.1-5552.sock test > test.sql
radha:~/mysql-build/mysql-4.1/client patg$ vi test.sql \
> 
radha:~/mysql-build/mysql-4.1/client patg$ ./mysql -uroot -S /tmp/mysqld-4.1-5552.sock test < test.sql 

mysql> select ord(name) from test;
+-----------+
| ord(name) |
+-----------+
|       157 |
+-----------+
1 row in set (0.07 sec)

mysql> select ord(name) from test;
+-----------+
| ord(name) |
+-----------+
|       157 |
+-----------+
1 row in set (0.25 sec)

mysql> select version();
+------------------+
| version()        |
+------------------+
| 4.1.15-debug-log |
+------------------+
1 row in set (0.00 sec)