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

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.