Volkan YAZICI wrote:
>On Jun 13 10:20, 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?
>>
>>
>
>IMHO, it might be better if we'd support a syntax like
>
> pg_dump --csv=opt0,para0:opt2,opt3
>
>This can save us from the pg_dump parameter pollution a little bit.
>
>Furthermore, I think CSV format for the dump files can be maintained
>better under an external project. (pgFoundry?) By this way, main
>developers will be able to cope with their own core problems while
>other users/developers can contribute on the CSV code easily. And if
>any user will ever want to get CSV functionality in the pg_dump,
>he/she will just issue a --csv parameter (with the above syntax) and
>pg_dump will make a suitable dlopen() call for the related (CSV)
>module. Anyway, this is just an idea for modularity; but the main
>thing I try to underline is to give pg_dump a module functionality for
>similar problems.
>
>
>
There are some problems with this, though:
. FORCE QUOTE is table specific, and COPY will barf if you name a column
that isn't on the table. Providing for this option would involve lots
more code in pg_dump, as we'd have to filter the list according to the
column names in each table.
. specifying arbitrary chars for quote, escape and delimiter could be
tricky from the command line, especially if you want to specify a tab
delimiter or backslash escape.
cheers
andrew
