On 10 March 2014 23:44, Tom Lane wrote: > Unfortunately, while testing it I noticed that there's a potentially > fatal backwards-compatibility problem, namely that the "COPY n" status > gets printed on stdout, which is the same place that COPY OUT data is > going. While this isn't such a big problem for interactive use, usages > like this one are pretty popular: > > psql -c 'copy mytable to stdout' mydatabase | some-program > > With the patch, "COPY n" gets included in the data sent to some-program, > which never happened before and is surely not what the user wants. > The same if the -c string uses \copy. > > There are several things we could do about this: > > 1. Treat this as a non-backwards-compatible change, and document that > people have to use -q if they don't want the COPY tag in the output. > I'm not sure this is acceptable. > > 2. Kluge ProcessResult so that it continues to not pass back a PGresult > for the COPY TO STDOUT case, or does so only in limited circumstances > (perhaps only if isatty(stdout), for instance).
> I'm inclined to think #2 is the best answer if we can't stomach #1. Is it OK to have different status output for different flavor of COPY command? I am afraid that It will become kind of inconsistent result. Also not providing the command result status may be inconsistent from behavior of any other SQL commands. I agree that it breaks the backward compatibility but I am not sure if anyone is so tightly coupled with this ( or whether they will be effected with additional status result). To me option #1 seems to be more suitable specially since there is an option to disable the status output by giving -q. Please provide your opinion or let me know If I have missed something. 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
