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 : 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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > >
