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
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? |