On Wed, May 17, 2017 at 2:39 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Vaishnavi Prabakaran <vaishnaviprabaka...@gmail.com> writes:
>>> Tom Lane wrote:
>>>> BTW, it would be a good idea for somebody to check this out on Windows,
>>>> assuming there's a way to generate a keyboard EOF signal there.
>> Ctrl-Z + Enter in windows generates EOF signal. I verified this issue and
>> it is not reproducible in windows.
> Thanks for checking.  So that's two major platforms where it works "as
> expected" already.

Ah... the reason this is happening is that BSD-derived fread()
implementations return immediately if the EOF flag is set[1], but
others do not.  At a guess, not doing that is probably more conformant
with POSIX ("... less than nitems only if a read error or end-of-file
is *encountered*", which seems to refer to the underlying condition
and not the user-clearable EOF flag).

We are neither clearing nor checking the EOF flag explicitly, and that
only works out OK on fread implementation that also ignore it.

Tom Lane <t...@sss.pgh.pa.us> wrote (further upstream):
> If we're going
> to go out of our way to make it work, should we mention it in psql-ref?

I went looking for the place to put that and found that it already says:

        For <literal>\copy ... from stdin</>, data rows are read from the same
        source that issued the command, continuing until <literal>\.</literal>
        is read or the stream reaches <acronym>EOF</>.

That's probably referring to the "outer" stream, such as a file that
contains the COPY ... FROM STDIN command, but doesn't it seem like a
general enough statement to cover ^d in the interactive case too?

Here's a version incorporating your other suggestions and a comment to explain.


Thomas Munro

Attachment: clear-copy-stream-eof-v2.patch
Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to