Bonjour Daniel,
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.
Patch applies cleanly, compiles, make check is ok.
However, it does not contain any tests (bad:-) nor documentation (hmmm...
maybe none needed, though).
Is this just kind of a bug fix? Beforehand the documentation says "\g fn"
sends to file, but that was not happening with COPY, and now it does as it
says?
A question: if opening the output file fails, should not the query be
cancelled and an error be reported? Maybe it is too late for that. It
seems that "SELECT pg_sleep(10) \g /bad/file" fails but executes the query
nevertheless.
ISTM that overriding copystream on open failures is not necessary, because
its value is already NULL in this case.
I'd suggest that is_pipe should be initialized to false, otherwise it is
unclear from the code when it is set before use, and some compilers may
complain.
--
Fabien.
