COPY table FROM STDIN doesn't show count tag

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.

Thanks and Regards,
Kumar Rajeev Rastogi

On Fri, Oct 18, 2013 at 7:37 AM, 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.
>
>
>
> Thanks and Regards,
>
> Kumar Rajeev Rastogi

Please add your patch to the currently-open CommitFest so that it does
not get forgotten:

https://commitfest.postgresql.org/action/commitfest_view/open

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 21 October 2013 20:48, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>On Fri, Oct 18, 2013 at 7:37 AM, 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.
>>
>>
>
>Please add your patch to the currently-open CommitFest so that it does not get forgotten:
>
>https://commitfest.postgresql.org/action/commitfest_view/open

Added to the currently-open CommitFest.

Thanks and Regards,
Kumar Rajeev Rastogi

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 :

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.

>
>
> *Thanks and Regards,*
>
> *Kumar Rajeev Rastogi *
>
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>