From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] multiline CSV fields |
Date: | 2004-12-03 00:27:03 |
Message-ID: | 41AFB2D7.9020000@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>
>>+ if (!embedded_line_warning && (c == '\n' || c == '\r') )
>>+ {
>>+ embedded_line_warning = true;
>>+ elog(WARNING,
>>+ "CSV fields with embedded linefeed or carriage return "
>>+ "characters might not be able to be reimported");
>>+ }
>>
>>
>
>What about forcibly translating them to the two-character sequences \n
>or \r? Or is that not considered a CSV-compatible representation?
>
>
>
>
Not compatible AFAIK. Certainly not portably. And the warning would
still be true, because we don't do this unescaping on the way back in. I
think the way the comment in the patch suggests and previous emails have
discussed is the right way to go with this - I will attend to it after
we branch ;-)
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2004-12-03 00:28:06 | Re: 8.0RC1 tomorrow |
Previous Message | Peter Eisentraut | 2004-12-03 00:25:43 | Re: 8.0RC1 tomorrow |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-12-03 01:20:41 | Re: Unicode characters above 0x10000 #2 |
Previous Message | Tom Lane | 2004-12-03 00:10:51 | Re: [HACKERS] multiline CSV fields |