From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, matthew(at)zeut(dot)net, bbartlett(at)softwareanalytics(dot)com, jd(at)commandprompt(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CSV mode option for pg_dump |
Date: | 2006-06-13 14:34:04 |
Message-ID: | 20060613143404.GF19212@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 13, 2006 at 10:20:53AM -0400, Bruce Momjian wrote:
>
> Good point. The number of CSV options would be hard to support for
> pg_dump. Any thoughts from anyone on how to do that cleanly? Could we
> just support the default behavior?
What this tells me is that we need a tool somewhere between psql and
pg_dump, say, pgquery. It's sole purpose in life is to generate output
from various queries. Because it's a seperate tool there's no question
of psql or pg_dump being able to parse them.
While you're at it, you could add modules to support many different
output styles, like CSV, XML, Excel format, HTML, etc.
This I beleive would take the load off psql to provide many different
output styles, as well as the load off pg_dump to produce
parsable-by-third-party output.
Thoughts?
Side note: In my experience Excel happily slurps up tab delimited
output, so I'm not sure why all of this is an issue in the first place.
Have a ncie day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Volkan YAZICI | 2006-06-13 14:44:19 | Re: CSV mode option for pg_dump |
Previous Message | Bruce Momjian | 2006-06-13 14:20:53 | Re: CSV mode option for pg_dump |