Re: CSV mode option for pg_dump

From: "Bill Bartlett" <bbartlett(at)softwareanalytics(dot)com>
To: "'Andrew Dunstan'" <andrew(at)dunslane(dot)net>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "'PG Hackers'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CSV mode option for pg_dump
Date: 2006-06-12 19:04:55
Message-ID: 0f1801c68e53$19b7bf20$1e00a8c0@bartletthome.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] 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 <andrew(at)dunslane(dot)net> 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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2006-06-12 19:05:07 Re: Non-transactional pg_class, try 2
Previous Message Greg Stark 2006-06-12 19:01:48 Re: ADD/DROP INHERITS