Re: multiline CSV fields - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: multiline CSV fields
Date
Msg-id 200411301757.iAUHvwU22351@candle.pha.pa.us
Whole thread Raw
In response to Re: multiline CSV fields  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: multiline CSV fields  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan wrote:
> 
> 
> Greg Stark wrote:
> 
> >Personally I find the current CSV support inadequate. It seems pointless to
> >support CSV if it can't load data exported from Excel, which seems like the
> >main use case. 
> >  
> >
> 
> OK, I'm starting to get mildly annoyed now. We have identified one 
> failure case connected with multiline fields. Even in the multiline 
> case, I expect that the embedded newlines will usually match those of 
> the CSV file, in which case there will be no failure. It's a very big 
> step from there to the far more general "can't load data exported from 
> Excel". Or did you have some other limitation in mind?
> 
> FWIW, I don't make a habit of using multiline fields in my spreadsheets 
> - and some users I have spoken to aren't even aware that you can have 
> them at all.

I am wondering if one good solution would be to pre-process the input
stream in copy.c to convert newline to \n and carriage return to \r and
double data backslashes and tell copy.c to interpret those like it does
for normal text COPY files.  That way, the changes to copy.c might be
minimal; basically, place a filter in front of the CSV file that cleans
up the input so it can be more easily processed.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: [Testperf-general] Re: 8.0beta5 results w/ dbt2
Next
From: Bruce Momjian
Date:
Subject: Re: Increasing the length of