On Wed, Mar 12, 2014 at 12:09 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> David Johnston <pol...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to