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
