From: | Patrick B Kelly <pbk(at)patrickbkelly(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: multiline CSV fields |
Date: | 2004-11-12 15:45:50 |
Message-ID: | ED80A94A-34C1-11D9-B14C-000A958A3956@patrickbkelly.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Nov 12, 2004, at 12:20 AM, Tom Lane wrote:
> Patrick B Kelly <pbk(at)patrickbkelly(dot)org> writes:
>> I may not be explaining myself well or I may fundamentally
>> misunderstand how copy works.
>
> Well, you're definitely ignoring the character-set-conversion issue.
>
I was not trying to ignore the character set and encoding issues but
perhaps my assumptions are naive or overly optimistic. I realized that
quotes are not as consistent as the NL characters but I was assuming
that some encodings would escape to ASCII or a similar encoding like
JIS Roman that would simplify recognition of the quote character.
Unicode files make recognizing other punctuation like the quote fairly
straightforward and to the naive observer, the code in CopyReadLine as
it is currently written appears to handle multi-byte encodings such as
SJIS that may present characters below 127 in trailing bytes.
As I said, perhaps I was oversimplifying. Is there a regression test
set of input files for that I could review to see all of the supported
encodings?
Patrick B. Kelly
------------------------------------------------------
http://patrickbkelly.org
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg I.Ivanov | 2004-11-12 17:20:20 | Database reverse engineering |
Previous Message | Andrew Dunstan | 2004-11-12 09:15:40 | Re: multiline CSV fields |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-11-12 17:59:27 | Re: Open Items |
Previous Message | Andrew Dunstan | 2004-11-12 09:15:40 | Re: multiline CSV fields |