| Bug #13318 | "mysqldump --skip-extended-insert --hex-blob" produces wrong result 0x | ||
|---|---|---|---|
| Submitted: | 19 Sep 2005 11:16 | Modified: | 2 Dec 2005 3:25 |
| Reporter: | Alexander Barkov | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) |
| Version: | 4.1.x, 5.0.x | OS: | |
| Assigned to: | Jim Winstead | CPU Architecture: | Any |
[13 Oct 2005 17:54]
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/internals/31052
[24 Nov 2005 1:26]
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/internals/32631
[1 Dec 2005 8:35]
Alexander Barkov
This one looks ok to push for me.
[2 Dec 2005 2:33]
Jim Winstead
Fixed in 5.0.17 and 5.1.4.
[2 Dec 2005 3:25]
Paul DuBois
Noted in 5.0.17, 5.1.4 changelogs.
Description: "mysqldump --skip-extended-insert --hex-blob" produces wrong output with empy BINARY and BLOB types: mysql> create table t1 (a binary(1), b blob); mysql> insert into t1 values ('',''); If you now run "mysqldump --skip-extended-insert --hex-blob test t1", empty values are displayed as 0x: INSERT INTO `t1` VALUES (0x,0x); How to repeat: See above. Suggested fix: Expected result is to use regular string notation on empty values: INSERT INTO `t1` VALUES ('','');