2018-01-27 15:22 GMT+01:00 Daniel Verite <dan...@manitou-mail.org>: > 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? >
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 >
