> We are able to generate html/tex/markdown formats on client side. CSV is > more primitive, but much more important data format, so it should not be a > problem. But I remember some objections related to code duplication.
While experimenting with adding csv as an output format (similar to unaligned except that it quotes with CSV rules), I find out that we can already do this:
\o | client-side-program with arguments or \o /path/to/file.csv COPY (select query) TO STDOUT CSV [HEADER] ; \o
This can be used to route multiple resultsets into multiple programs or files without the minor drawbacks of \copy (single line formatting, no variables interpolation), or psql -c "COPY (query) TO STDOUT.." >file.csv which is a bit rigid (single redirect).
OTOH I notice that this simpler form with a right-side argument of \g: =# COPY (select 1) TO STDOUT CSV HEADER \g /tmp/file.csv outputs to the console rather into a file. Not sure why it acts differently than \o and whether it's intentional.
Anyway I think the above sequence with \o already does everything that is being proposed as an alternative to \graw, or am I missing something?
There is one difference, hard to say how much is important - you have to wrap your query to COPY command. That is not too friendly.
Regards
Pavel
What \o + COPY CSV lacks compared to a csv output format is the ability to export results from meta-commands in csv, such as \g in \x mode or \gx, \crosstabview, \d, \l...
The other problem with \o |program + COPY CSV is that it's not easy to discover that combination. It's more obvious if we have csv explicitly listed as an output format.
I'll post the patch implementing that in a new thread and we'll see how it goes.
Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
