On 19 November 2013, Amit Khandekar wrote: >On 18 November 2013 18:00, Rajeev rastogi ><rajeev.rast...@huawei.com<mailto:rajeev.rast...@huawei.com>> wrote: >>On 18 November 2013, Amit Khandekar wrote: > >>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. OK..Thanks >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. This looks to be an issue without our new patch also. Like I tried following command and output was as follows: rajeev@linux-ltr9:~/9.4gitcode/install/bin> ./psql -d postgres -c "\copy tbl to 'new.txt';insert into tbl values(55);" rajeev@linux-ltr9:~/9.4gitcode/install/bin> cat new.txt 5 67 5 67 2 2 99 1 1 INSERT 0 1 I have fixed the same as per your suggestion by resetting the pset.queryFout after the function call "handleCopyOut". Please let me know in-case of any other issues. Thanks and Regards, Kumar Rajeev Rastogi
copydefectV3.patch
Description: copydefectV3.patch
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
