On Wed, Mar 12, 2014 at 12:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
This is reasonably similar to what we already do for SELECT, isn't it?I mean, the server always sends back a command
tag,but psql
sometimes opts not to print it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
