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

From: Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
To: Amit Khandekar <amit(dot)khandekar(at)enterprisedb(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: COPY table FROM STDIN doesn't show count tag
Date: 2013-11-18 12:30:59
Message-ID: BF2827DCCE55594C8D7A8F7FFD3AB7713DDAA8BD@SZXEML508-MBX.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 18 November 2013, Amit Khandekar wrote:
>> On 18 October 2013 17:07, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com<mailto: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<http://www.postgresql.org/message-id/CE85A517.4878E%25tim.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 have modified the patch as per your comment and same is attached with this mail.
Please let me know in-case of any other issues or suggestions.

Thanks and Regards,
Kumar Rajeev Rastogi

Attachment Content-Type Size
copydefectV2.patch application/octet-stream 5.3 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-11-18 12:36:35 Re: Sequence Access Method WIP
Previous Message Kohei KaiGai 2013-11-18 12:25:40 Re: Custom Scan APIs (Re: Custom Plan node)