Re: COPY table FROM STDIN doesn't show count tag

On 18 November 2013 18:00, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com> wrote:

> On 18 November 2013, Amit Khandekar wrote:
>
> >> On 18 October 2013 17:07, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
> wrote:
>
> >>From the following mail, copy behaviour between stdin and normal file
> having some inconsistency.
>
> >>
> http://www.postgresql.org/message-id/CE85A517.4878E%tim.kane@gmail.com
>
> >>The issue was that if copy execute "from stdin", then it goes to the
> server to execute the command and then server request for the input, it
> sends back the control to client to enter the data. So
>
> >> once client sends the input to server, server execute the copy command
> and sends back the result to client but client does not print the result
> instead it just clear it out.
>
> >> Changes are made to ensure the final result from server get printed
> before clearing the result.
>
> > Please find the patch for the same and let me know your suggestions.
>
> >In this call :
>
> > success = handleCopyIn(pset.db,
> pset.cur_cmd_source,
>
> >
> PQbinaryTuples(*results), &intres) && success;
>
> >
>
> > if (success && intres)
>
> > success =
> PrintQueryResults(intres);
>
> >
>
> >Instead of handling of the result status this way, what if we use the
> ProcessResult() argument 'result' to pass back the COPY result status to
> the caller ? We already call PrintQueryResults(results) after the
> ProcessResult() call. So we don't have to have a
>
> > COPY-specific PrintQueryResults() call. Also, if there is a subsequent
> SQL command in the same query string, the consequence of the patch is that
> the client prints both COPY output and the last command output. So my
> suggestion would also allow us
>
> > to be consistent with the general behaviour that only the last SQL
> command output is printed in case of multiple SQL commands. Here is how it
> gets printed with your patch :
>
> Thank you for valuable comments. Your suggestion is absolutely correct.
>
> >psql -d postgres -c "\copy tab from '/tmp/st.sql' delimiter ' '; insert
> into tab values ('lll', 3)"
>
> >COPY 1
>
> >INSERT 0 1
>
> >
>
> >This is not harmful, but just a matter of consistency.
>
> I hope you meant to write test case as *psql -d postgres -c "\copy tab
> from stdin; insert into tab values ('lll', 3)", *as if we are reading
> from file, then the above issue does not come.
>
I meant COPY with a slash. \COPY is equivalent to COPY FROM STDIN. So the
issue can also be reproduced by :
\COPY tab from 'client_filename' ...

> I have modified the patch as per your comment and same is attached with
> this mail.
>

Thanks. The COPY FROM looks good.

With the patch applied, \COPY TO 'data_file' command outputs the COPY
status into the data file, instead of printing it in the psql session.

postgres=# \copy tab to '/tmp/fout';
postgres=#

$ cat /tmp/fout
ee 909
COPY 1

This is probably because client-side COPY overrides the pset.queryFout with
its own destination file, and while printing the COPY status,
the overridden file pointer is not yet reverted back.

Please let me know in-case of any other issues or suggestions.
>
>
>
> *Thanks and Regards,*
>
> *Kumar Rajeev Rastogi *
>
>
>