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 (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers