Re: CSV mode option for pg_dump

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
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, pgsql-hackers(at)postgresql(dot)org
Subject: Re: CSV mode option for pg_dump
Date: 2006-06-13 15:09:19
Message-ID: 448ED51F.8080902@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

Although I don't see a real need for the feature, I do think that if we
were to support "1" (well two if you include the already tab delimited)
csv output it would be a large amount of bloat.

Perhaps we could pick "1" output, say comma delimted with quoted fields?

"foo","bar ","baz"

Joshua D. Drake

>
> ---------------------------------------------------------------------------
>
> Tom Lane wrote:
>> "Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
>>> I wish I could understand why people are so keen to make other people turn
>>> handsprings in order to avoid a feature which, as Bruce points out, is
>>> already on the TODO list, and which, by my 10 minute analysis, would involve
>>> almost trivial code impact and risk. If this involved major impact I might
>>> understand, but it really doesn't.
>> Supporting all of the CSV options in pg_dump would involve major bloat
>> in its option set, and it already has far too many options. If it were
>> just a matter of adding a "--csv" switch I wouldn't be complaining, but
>> there are half a dozen more sub-options, and it seems like every time we
>> turn around someone is finding a reason for another one. Propagating
>> all that cruft through pg_dump would be a PITA, and updating it to track
>> future additions would be too.
>>
>> Furthermore, the entire rationale for the feature is predicated on the
>> claim that programs other than pg_restore might find it useful. But
>> this conveniently ignores the fact that if there are any such programs
>> in existence, what this will really do is BREAK them, because they won't
>> be able to cope with all the variants that pass for CSV.
>>
>> My opinions would be less negative if I thought that CSV were a
>> well-defined format that would never change. I don't believe that it
>> has either property, however, and so I'm against letting it get into our
>> dump file format. I think we'll just live to regret it if we do.
>>
>> regards, tom lane
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 9: In versions below 8.0, the planner will ignore your desire to
>> choose an index scan if your joining column's datatypes do not
>> match
>>
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-06-13 15:16:07 Re: timezones to own config file
Previous Message Tom Lane 2006-06-13 15:01:40 Re: Running a query twice to ensure cached results.