On Fri, Mar 11, 2022 at 7:38 PM Daniel Verite <daniel@xxxxxxxxxxxxxxxx> wrote: >> Dominique Devienne wrote: > > These values are 'normal'. I'm not used to CSV, but I suppose such newlines > > must be encoded, perhaps as \n, since AFAIK CSV needs to be 1 line per row, no? > > No, but such fields must be enclosed by double quotes, as documented > in RFC 4180 https://datatracker.ietf.org/doc/html/rfc4180 Hi Daniel. OK, good to know, thanks. > Consider this output: > psql> COPY (values (1, E'ab\ncd'), (2,'efgh')) TO STDOUT CSV; > 1,"ab > cd" > 2,efgh yes, this is consistent with what I am seeing in the debugger. The value is indeed double-quoted, and definitely contains a _raw_ '\n' newline, and not an encoded "backslash then n", as David was writing. > That's 2 records on 3 lines. > If you feed this to a parser and it chokes on it, it means that it's not a valid CSV parser. I never pretended that parser to be a CSV parser :). It's a naive "wc -l" equivalent written by someone else. And it's comparing PostgreSQL CSV output to some old legacy "CSV" output that's home grown, which does encode newlines as '\\' and 'n', and which most likely is not RFC compliant (I'm not suprised! :))). In my case, backward-compat is more important than "compliancy" (if that's a word!), so I can easily do that "\n" encoding myself, as a post-processing on the buffer I get back. Thank you for the help. --DD PS: And David, no, it's not my wrapper that's at fault here :). It's a thin wrapper, that's just easier, terser, and safer (RAII) to use compared to naked libpq.
