Pavel Stehule wrote:
> 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?
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