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

From: Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
To: Amit Khandekar <amit(dot)khandekar(at)enterprisedb(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: COPY table FROM STDIN doesn't show count tag
Date: 2013-11-27 04:29:50
Message-ID: BF2827DCCE55594C8D7A8F7FFD3AB7713DDAE7A9@SZXEML508-MBX.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 26 November 2013, Amit Khandelkar wrote:
>>Now if \copy command is called then, we are setting the appropriate value of _psqlSettings->copystream in do_copy and same is being used inside handleCopyIn() and handleCopyOut(). Once the \copy command execution finishes, we are resetting
>> the value of _psqlSettings->copystream to NULL. And if COPY(No slash) command is used, then in that case _psqlSettings->copystream will be NULL. So based on this value being NULL, copyStream will be assigned as stdout/stdin depending on
>>TO/FROM respectively inside the function handleCopyOut()/handleCopyIn().
>>Also in order to address the queries like
>>./psql -d postgres -c "\copy tbl to '/home/rajeev/9.4gitcode/install/bin/data/temp.txt'; copy tbl from stdin;"
>>Inside the function ProcessResult, we check that if it is the second cycle and result status is COPY OUT or IN, then we reset the value of _psqlSettings->copystream to NULL, so that it can take the value as stdout/stdin for further processing.

>Yes, that's right, the second cycle should not use pset.copyStream.

>>handleCopyOut(PGconn *conn, FILE *copystream, PGresult **res)
>>{
>> bool OK = true;
>> char *buf;
>> int ret;
>>- PGresult *res;
>>+
>>+ if (!copystream)
>>+ copystream = stdout;

>It should use pset.queryFout if it's NULL. Same in hadleCopyIn(). Otherwise, the result of the following command goes to stdout, when it should go to the output file :
>psql -d postgres -o /tmp/p.out -c "copy tab to stdout"
Yes you are right, I have changed it accordingly.

>>+ /*
>>+ * If this is second copy; then it will be definately not \copy,
>>+ * and also it can not be from any user given file.
>>+ * So reset the value of copystream to NULL, so that read/wrie
>>+ * happens from stdin/stdout.
>>+ */
>>+ if (!first_cycle)
>>+ pset.copyStream = NULL;

>Let ProcessResult() not change pset.copyStream. Let only do_copy() update it. Instead of the above location, I suggest, just before calling handleCopyOut/In(), we decide what to pass them as their copyStream parameter depending upon whether it is
>first cycle or not.
OK. I have changed as per your suggestion.

Also I had removed the below line
if (copystream == pset.cur_cmd_source)
from the function handleCopyIn in my last patch itself. Reason for removal is that as per the earlier code the condition result was always true.

Please provide your opinion.

Thanks and Regards,
Kumar Rajeev Rastogi

Attachment Content-Type Size
copyerrorV5.patch application/octet-stream 7.9 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-11-27 04:41:40 Re: Assertions in PL/PgSQL
Previous Message Haribabu kommi 2013-11-27 04:27:35 Re: New option for pg_basebackup, to specify a different directory for pg_xlog