Here's me speaking up -- I'd definitely use it!   As a quick way to pull
data into Excel to do basic reports or analysis, a CSV format would be
great.  Some of our users currently pull data into Excel for quickie
analysis, but creating fixed-width data via psql requires them to parse
the data and dumping anything via pg_dump with any delimiter (tabs,
etc.) usually doesn't work due to the delimiters being embedded in the
real data.

- Bill

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Andrew Dunstan
> Sent: Monday, June 12, 2006 2:16 PM
> To: Tom Lane
> Cc: PG Hackers
> Subject: Re: [HACKERS] CSV mode option for pg_dump
> 
> 
> Tom Lane wrote:
> > Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >   
> >> Something someone said on IRC just now triggered a little 
> memory  ... 
> >> I
> >> think we should provide an option to have pg_dump work in CSV mode 
> >> rather than text mode. This probably doesn't have much 
> importance in the 
> >> case of text dumps, but in custom or tar dumps where you 
> might want to 
> >> get at individual data members, having an option for CSVs 
> that you want 
> >> to load into some other product might be nice.
> >>     
> >
> > This is silly.  You'd just COPY the particular table you 
> want, not use 
> > pg_dump.  pg_dump's already got an unreasonably large number of 
> > options without adding ones that have essentially zero use. 
>  Also, I 
> > think there are sufficient grounds to worry about whether a 
> CSV dump 
> > would always reload correctly --- we already know that 
> that's a poorly 
> > thought out "standard".
> >
> >     
> >   
> 
> Well, if you have dozens or hundreds of tables it might well be more 
> convenient.
> 
> As for not reloading - I went to some trouble to make sure 
> that we could 
> reload what we dumped, exactly, unless the force options are used. I 
> might have made a bug in that, but it isn't dependent on the 
> particular 
> CSV format used.
> 
> Naturally you won't have a use for it, but I suspect others might (in 
> which case they had better speak up ;-) )
> 
> I suppose the alternative would be to write a little tool in perl or 
> whatever to do the same thing for you. Maybe a good pgfoundry project.
> 
> cheers
> 
> andrew
> 
> 
> ---------------------------(end of 
> broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
> 


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq

Reply via email to