Re: Alternative to \copy in psql modelled after \g

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Subject: Re: Alternative to \copy in psql modelled after \g
Date: 2018-12-16 14:06:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I wrote:

> I admit that if we could improve \g to handle COPY, it would be more
> elegant than the current proposal adding two meta-commands.
> But the copy-workflow and non-copy-workflow are different, and in
> order to know which one to start, \g would need to analyze the query

It turns out I was wrong on this. The workflows are different but when
psql receives the first PGresult, it's still time to handle the I/O
redirection. It just differs from \copy in the case of an error:
\copy won't even send a command to the server if the local output
stream can't be opened, whereas COPY \g would send the command, and
will have to deal with the client-side error afterwards.

Well, except that up to now, COPY ... TO STDOUT \g file or \g |command
has been ignoring "file" or "|command", which is arguably a bug as Tom
puts it in another discussion in [1].

So as a replacement for the \copyto I was proposing earlier, PFA a patch
for COPY TO STDOUT to make use of the argument to \g.

[1] bug #15535

Best regards,
Daniel Vérité
PostgreSQL-powered mailer:
Twitter: @DanielVerite

Attachment Content-Type Size
psql-copyout-g.patch text/plain 2.5 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-12-16 14:28:46 Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query
Previous Message Tomas Vondra 2018-12-16 14:00:27 Re: [HACKERS] logical decoding of two-phase transactions