Re: COPY table FROM STDIN doesn't show count tag

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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-13 17:55:07
Message-ID: 5007.1394733307@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com> writes:
> [ updated patch ]

I've committed this patch with additional revisions.

> Based on my analysis, I observed that just file pointer comparison may not be sufficient
> to decide whether to display command tag or not. E.g. imagine below scenario:

> psql.exe -d postgres -o 'file.dat' -c " \copy tbl to 'file.dat';"

I don't think it's our responsibility to avoid printing both data and
status to the same place in such cases; arguably, in fact, that's exactly
what the user told us to do. The important thing is to avoid printing
both for the straightforward case of COPY TO STDOUT. For that, file
pointer comparison is the right thing, since the option-parsing code will
set copysource to match queryFout in exactly the relevant cases.

In any case, this revised patch suppressed the status print in *all*
COPY_OUT cases, which surely seems like throwing the baby out with the
bathwater.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2014-03-13 18:10:27 Re: GIN improvements part2: fast scan
Previous Message Andrew Dunstan 2014-03-13 17:24:44 Re: JSON Patch (RFC 6902) support?