Re: multiline CSV fields - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: multiline CSV fields
Date
Msg-id 41AB2B7C.6060901@dunslane.net
Whole thread Raw
In response to Re: multiline CSV fields  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: multiline CSV fields  (Kris Jurka <books@ejurka.com>)
Re: multiline CSV fields  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers

Bruce Momjian wrote:

>Andrew Dunstan wrote:
>  
>
>>>OK, then should we disallow dumping out data in CVS format that we can't
>>>load?  Seems like the least we should do for 8.0.
>>>
>>> 
>>>
>>>      
>>>
>>As Tom rightly points out, having data make the round trip was not the 
>>goal of the exercise. Excel, for example, has no trouble reading such 
>>data (or at least my installation of it).
>>
>>Personally I consider CSVs with line end chars embedded in fields to be 
>>broken anyway, but this was something that was specifically mentioned 
>>when we were discussing requirements, which is why I coded for it.
>>    
>>
>
>OK, I am pretty uncomforable with this but you know this usage better
>than I do.  Should we issue a warning message stating it will not be
>able to be reloaded?
>  
>

If it bothers you that much. I'd make a flag, cleared at the start of 
each COPY, and then where we test for CR or LF in CopyAttributeOutCSV, 
if the flag is not set then set it and issue the warning.

Longer term I'd like to be able to have a command parameter that 
specifies certain fields as multiline and for those relax the line end 
matching restriction (and for others forbid multiline altogether). That 
would be a TODO for 8.1 though, along with optional special handling for 
first line column headings.

cheers

andrew


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: multiline CSV fields
Next
From: Simon Riggs
Date:
Subject: Re: Documentation on PITR still scarce