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

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

On 27 November 2013 09:59, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com> wrote:

> On 26 November 2013, Amit Khandelkar wrote:
>
>
> On 26 November 2013 18:59, Amit Khandekar <amit(dot)khandekar(at)enterprisedb(dot)com
> > wrote:
>
>>
>>
>>
>> On 25 November 2013 15:25, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
>> wrote:
>>
>>> OK. I have revised the patch as per the discussion.
>>>
>> Could you please submit only the \COPY fix first ? The attached patch
>> also contains the fix for the original COPY status fix.
>>
> Can you please submit the \COPY patch as a separate patch ? Since these
are two different issues, I would like to have these two fixed and
committed separately. You can always test the \COPY issue using \COPY TO
followed by INSERT.