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

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "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-25 15:38:39
Message-ID: alpine.DEB.2.21.1812251618010.32444@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Banck 2018-12-25 16:29:06 Re: Progress reporting for pg_verify_checksums
Previous Message Tom Lane 2018-12-25 15:22:30 Re: Minor comment fix for pg_config_manual.h