From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | David Johnston <polobo(at)yahoo(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: COPY table FROM STDIN doesn't show count tag |
Date: | 2014-03-12 18:26:39 |
Message-ID: | 17600.1394648799@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Mar 12, 2014 at 12:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
Right, the analogy to SELECT gives some comfort that this is reasonable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2014-03-12 18:27:56 | Re: Patch: Show process IDs of processes holding a lock; show relation and tuple infos of a lock to acquire |
Previous Message | Stephen Frost | 2014-03-12 18:25:13 | Re: db_user_namespace a "temporary measure" |