Bug #12564 | mysqldump behavior change --fields-terminated-by and server version 3 or 4,5 | ||
---|---|---|---|
Submitted: | 13 Aug 2005 6:30 | Modified: | 12 Apr 2006 17:01 |
Reporter: | James Day | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Documentation | Severity: | S3 (Non-critical) |
Version: | mysqldump 10.10, also one with 4.1 | OS: | Linux (linux) |
Assigned to: | Paul DuBois | CPU Architecture: | Any |
[13 Aug 2005 6:30]
James Day
[13 Aug 2005 6:32]
James Day
Originally reported on linux, checked on Windows XP.
[13 Aug 2005 10:57]
Aleksey Kishkin
tested against on suse 9.3, got the same results
[15 Oct 2005 1:11]
Patrick Galbraith
This isn't mysqldump - the problem is in the server: mysql> select * INTO outfile './foo3.txt' FIELDS TERMINATED BY '' ENCLOSED BY '' FROM widtest; Query OK, 2 rows affected (0.40 sec) mysql> \q Bye patg@krsna:~/mysql-build/mysql-4.1/client> vi ../mysql-test/var/master-data/foo3.txt 1 1 1 1 2 12345 123456789 1 So, the next step is to identify what controls this in the server.
[17 Oct 2005 20:59]
Patrick Galbraith
[22:53] <patg> monty: I have a table of int(4) and int(8), int(4) has 12345 in it, and int(8) has 123456789 in it, and the outfile has all 5 for the int(4) and all 9 for the int(8) [22:54] <monty> Patg, if you are using int(4) for an int with 12345, the output format will not work! [22:54] <monty> FIELDS TERMINATEd BY ""requires that your data is not outside of your limits. if it is, you are (and have always been) on your own [22:54] <patg> monty: the way the docs describe it, it should dump 12345 as 1234 and 123456789 as 12345678 [22:55] <patg> monty: hmmm.... [22:55] <monty> No, that's not true anymore and doesn't have to be [22:55] <patg> monty: so, it's not supposed to truncate? [22:55] <monty> If you are outside of the limits, there is no guranteees [22:55] <monty> no [22:55] <patg> monty: ok, then this is a documentation issue then.. [22:56] <monty> The simple reason is that truncating is more wrong than writing the whole number [22:56] <monty> I remember a change for this a long time ago, but it should have been documented in the change log (but of course, there is a chance we forgot...) [22:56] <patg> monty: I'm glad to learn this ;) I suppose there are often cases where users are historically used to the way mysql once worked even if 'working' was wrong, and when that's changed, they think it's a bug. <monty> Yes, but if they expect int(4) to trunk, they are not using the format in an 'expected' manner
[19 Jan 2006 22:32]
Mike Hillyer
Changing status to Verified, category to documentation as Documenting status is strictly for bugfixes requiring a changelog entry.
[12 Apr 2006 17:01]
Paul DuBois
Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant product(s). Additional info: Fixed-row format dump/reload behavior for LOAD DATA/SELECT ... INTO OUTFILE changed in 4.1.12/5.0.6: Declared display width is ignored. Instead a field large enough to hold all values is used. I've updated the LOAD DATA INFILE section, the 4.1.12/5.0.6 changelog sections, and the 4.1 and 5.0 upgrade sections.