|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|
|Views:||Raw Message | Whole Thread | Download mbox|
> 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 .
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.
PostgreSQL-powered mailer: http://www.manitou-mail.org
|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|