David Johnston <polobo@yahoo.com> writes:
> Tom Lane-2 wrote
>> 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.
> I've mostly used copy to with files and so wouldn't mind if STDOUT had the
> COPY n sent to it as long as the target file is just the copy contents.
I think you're missing the point: the case I'm concerned about is exactly
that the target file is psql's stdout, or more specifically the same place
that the COPY status would get printed to.
>> 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).
> The main problem with this is that people will test by sending output to a
> TTY and see the COPY n. Although if it can be done consistently then you
> minimize backward incompatibility and encourage people to enforce quiet mode
> while the command runs...
Yeah, the inconsistency of behavior that this solution would cause is not
a good thing. My inclination now (see later traffic) is to suppress the
status report when the COPY destination is the same as pset.queryFout
(ie, a simple test whether the FILE pointers are equal). This would
suppress the status report for "\copy to stdout" and "COPY TO STDOUT"
cases, and also for "\copy to pstdout" if you'd not redirected queryFout
with \o.
regards, tom lane
