Re: COPY table FROM STDIN doesn't show count tag - Mailing list pgsql-hackers

From Tom Lane
Subject Re: COPY table FROM STDIN doesn't show count tag
Date
Msg-id 13673.1394639824@sss.pgh.pa.us
Whole thread Raw
In response to Re: COPY table FROM STDIN doesn't show count tag  (Rajeev rastogi <rajeev.rastogi@huawei.com>)
List pgsql-hackers
Rajeev rastogi <rajeev.rastogi@huawei.com> writes:
> On 11 March 2014 19:52, Tom Lane wrote:
>> After sleeping on it, I'm inclined to think we should continue to not
>> print status for COPY TO STDOUT.  Aside from the risk of breaking
>> scripts, there's a decent analogy to be made to SELECT: we don't print
>> a status tag for that either.

> It is correct that SELECT does not print conventional way of status tag but still it prints the number
> of rows selected (e.g. (2 rows)) along with rows actual value, which can be very well considered
> as kind of status. User can make out with this result, that how many rows have been selected.

> But in-case of COPY TO STDOUT, if we don't print anything, then user does not have any direct way of finding
> that how many rows were copied from table to STDOUT, which might have been very useful.

Uh, you mean other than the data rows that were just printed?  I fail
to see how this is much different from the SELECT case:

regression=# \copy int8_tbl to stdout
123     456
123     4567890123456789
4567890123456789        123
4567890123456789        4567890123456789
4567890123456789        -4567890123456789
regression=# 

(Note that I'm defining TO STDOUT from psql's perspective, ie the rows are
going to the queryFout file, which is the same place the COPY status would
get printed to.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: "Tomas Vondra"
Date:
Subject: Re: pgstat wait timeout (RE: contrib/cache_scan)
Next
From: Heikki Linnakangas
Date:
Subject: Re: GIN improvements part2: fast scan