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

From: Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-13 11:40:19
Message-ID: BF2827DCCE55594C8D7A8F7FFD3AB7713DDD8520@SZXEML508-MBX.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12 March 2014 23:57, Tom Lane Wrote:
> 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.

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';"

Though both destination files are same but file pointer will be different and hence
printing status in file 'file.dat' will overwrite some part of data copied to file.
Also we don't have any direct way of comparison of file name itself.
As I see \copy ... TO.. will print status only in-case of "\copy to pstdout" if -o option is given.

So instead of having so much of confusion and inconsistency that too for one very specific case,
I though not to print status for all case Of STDOUT and \COPY ... TO ...

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

I have modified the patch based on above analysis as:
1. In-case of COPY ... TO STDOUT, command tag will not be displayed.
2. In-case of \COPY ... TO ..., command tag will not be displayed.
3. In all other cases, command tag will be displayed similar as were getting displayed earlier.

I have modified the corresponding documentation.

Please find the attached revised patch.

Thanks and Regards,
Kumar Rajeev Rastogi

Attachment Content-Type Size
psql-copy-count-tag-20140313.patch application/octet-stream 10.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jozef Mlich 2014-03-13 12:06:00 Re: 9a57858f1103b89a5674f0d50c5fe1f756411df6
Previous Message Andres Freund 2014-03-13 11:24:13 Re: db_user_namespace a "temporary measure"