On 18 November 2013 18:00, Rajeev rastogi <rajeev.rast...@huawei.com> wrote:
> On 18 November 2013, Amit Khandekar wrote: > > >> On 18 October 2013 17:07, Rajeev rastogi <rajeev.rast...@huawei.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.k...@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 * > > >
