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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
