The following bug has been logged online: Bug reference: 3795 Logged by: Lou Duchez Email address: lou@paprikash.com PostgreSQL version: 8.3 beta 3 Operating system: Windows 2003 Description: pg_dump is mis-dumping columns containing line breaks Details: Hello, My copy of PostgreSQL has standard_conforming_strings set to "on", and when I attempt to pg_dump tables that have strings containing CR/LFs, the data dumps in a format that psql cannot then reload. The CR/LFs are preceded by a backslash ("\") in the dump but are not themselves "escaped" -- so instead of looking like this: line 1\nline2\nline3 it looks like this: line 1\ line 2\ line 3 And psql seems to be unable to handle data in that format. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

"Lou Duchez" <lou@paprikash.com> writes: > My copy of PostgreSQL has standard_conforming_strings set to "on", and when > I attempt to pg_dump tables that have strings containing CR/LFs, the data > dumps in a format that psql cannot then reload. It works fine here. Please provide a *complete* example of what you are doing. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings

lou@paprikash.com writes: > The two versions of PostgreSQL produce slightly different results. Yeah, that's an intentional change. > The 8.3 version, with the unescaped line breaks, confuses the heck out > of psql. Works fine for me --- I can load either dump file into either version of psql. Maybe your test case involves letting Windows mangle the line endings? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

I wrote: > Maybe your test case involves letting Windows mangle the line endings? On reflection, I'm sure that's exactly what's happening. I now remember that one of the reasons for the old dump behavior was to make COPY data a bit safer against line-ending mangling. I've reverted this rather ill-advised change in behavior, and added a note in the code to hopefully prevent anyone from making the same mistake again. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match