Rajeev rastogi 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 post
On 12 March 2014 23:57, Tom Lane Wrote:
> Robert Haas writes:
> > On Wed, Mar 12, 2014 at 12:09 PM, Tom Lane 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
Robert Haas writes:
> On Wed, Mar 12, 2014 at 12:09 PM, Tom Lane 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 sta
On Wed, Mar 12, 2014 at 12:09 PM, Tom Lane wrote:
> David Johnston writes:
>> Tom Lane-2 wrote
>>> 1. Treat this as a non-backwards-compatible change, and document that
>>> people have to use -q if they don't want the COPY tag in the output.
>>> I'm not sure this is acceptable.
>
>> I've mostly u
David Johnston writes:
> Tom Lane-2 wrote
>> 1. Treat this as a non-backwards-compatible change, and document that
>> people have to use -q if they don't want the COPY tag in the output.
>> I'm not sure this is acceptable.
> I've mostly used copy to with files and so wouldn't mind if STDOUT had t
Rajeev rastogi writes:
> On 11 March 2014 19:52, Tom Lane wrote:
>> After sleeping on it, I'm inclined to think we should continue to not
>> print status for COPY TO STDOUT. Aside from the risk of breaking
>> scripts, there's a decent analogy to be made to SELECT: we don't print
>> a status tag f
2014-03-12 7:10 GMT+01:00 David Johnston :
> Tom Lane-2 wrote
> > Unfortunately, while testing it I noticed that there's a potentially
> > fatal backwards-compatibility problem, namely that the "COPY n" status
> > gets printed on stdout, which is the same place that COPY OUT data is
> > going. Wh
Tom Lane-2 wrote
> Unfortunately, while testing it I noticed that there's a potentially
> fatal backwards-compatibility problem, namely that the "COPY n" status
> gets printed on stdout, which is the same place that COPY OUT data is
> going. While this isn't such a big problem for interactive use,
On 11 March 2014 19:52, Tom Lane wrote:
> After sleeping on it, I'm inclined to think we should continue to not
> print status for COPY TO STDOUT. Aside from the risk of breaking
> scripts, there's a decent analogy to be made to SELECT: we don't print
> a status tag for that either.
It is correc
Rajeev rastogi writes:
> On 10 March 2014 23:44, Tom Lane wrote:
>> Unfortunately, while testing it I noticed that there's a potentially
>> fatal backwards-compatibility problem, namely that the "COPY n" status
>> gets printed on stdout, which is the same place that COPY OUT data is
>> going. Whi
On 10 March 2014 23:44, Tom Lane wrote:
> Unfortunately, while testing it I noticed that there's a potentially
> fatal backwards-compatibility problem, namely that the "COPY n" status
> gets printed on stdout, which is the same place that COPY OUT data is
> going. While this isn't such a big prob
I wrote:
> Also, I'm thinking we should back-patch the aspects of the patch
> needed to fix the wrong-line-number issue. That appears to have been
> introduced in 9.2; older versions of PG get the above example right.
I've done that. For reference' sake, here's an updated patch against
HEAD with
Rajeev rastogi writes:
> On 12th December 2013, Rajeev Rastogi Wrote:
>> On 9th December, Amit Khandelkar wrote:
>>> But copystream can be different than pset.cur_cmd_source , right ?
>> As per the earlier code, condition result was always true. So pset.lineno
>> was always incremented.
>> In th
On 12th December 2013, Rajeev Rastogi Wrote:
>On 9th December, Amit Khandelkar wrote:
>>1. slashcopyissuev1.patch :- This patch fixes the \COPY issue.
>>You have removed the if condition in this statement, mentioning that it is
>>always true now:
>>- if (copystream == p
On 9th December, Amit Khandelkar wrote:
>1. slashcopyissuev1.patch :- This patch fixes the \COPY issue.
>You have removed the if condition in this statement, mentioning that it is
>always true now:
>- if (copystream == pset.cur_cmd_source)
>-
On 29 November 2013 19:20, Rajeev rastogi wrote:
> On 26 November 2013, Amit Khandelkar wrote:
>
> >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 i
On 26 November 2013, Amit Khandelkar wrote:
>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.
Please find the
On 27 November 2013 09:59, Rajeev rastogi wrote:
> On 26 November 2013, Amit Khandelkar wrote:
>
>
> On 26 November 2013 18:59, Amit Khandekar > wrote:
>
>>
>>
>>
>> On 25 November 2013 15:25, Rajeev rastogi
>> wrote:
>>
>>> OK. I have revised the patch as per the discussion.
>>>
>> Could you
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
>> t
On 25 November 2013 15:25, Rajeev rastogi 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.
Now if \copy command is called then, we are setting the appropri
On 25 November 2013, Amit Khandekar
mailto:amit.khande...@enterprisedb.com>> wrote:
>>>Ok. we will then first fix the \COPY TO issue where it does not revert back
>>>the overriden psql output file handle. Once this is solved, fix for both
>>>COPY FROM and COPY TO, like how it is done in the patc
On 22 November 2013 16:14, Rajeev rastogi wrote:
> On 21 November 2013, Amit Khandekar
> wrote:
>
> >Ok. we will then first fix the \COPY TO issue where it does not revert
> back the overriden psql output file handle. Once this is solved, fix for
> both COPY FROM and COPY TO, like how it is don
On 21 November 2013, Amit Khandekar
mailto:amit.khande...@enterprisedb.com>> wrote:
>Ok. we will then first fix the \COPY TO issue where it does not revert back
>the overriden psql output file handle. Once this is solved, fix for both COPY
>FROM and COPY TO, like how it is done in the patch earl
On 20 November, Amit Khandekar wrote:
I hope you meant to write test case as psql -d postgres -c "\copy tab from
stdin; insert into tab values ('lll', 3)", as if we are reading from file,
then the above issue does not come.
>>>I meant COPY with a slash. \COPY is equivalent to COPY FRO
On 19 November 2013, Amit Khandekar wrote:
>On 18 November 2013 18:00, Rajeev rastogi
>mailto:rajeev.rast...@huawei.com>> wrote:
>>On 18 November 2013, Amit Khandekar wrote:
> >>Please find the patch for the same and let me know your suggestions.
>>>In this call :
> >>
On 21 November 2013 10:13, Tom Lane wrote:
> Amit Khandekar writes:
> > Rather than a behaviour change, it is a bug that we are fixing. User
> > already expects to see copy status printed, so as per user there would be
> > no behaviour change.
>
> This is arrant nonsense. It's a behavior change
Amit Khandekar writes:
> Rather than a behaviour change, it is a bug that we are fixing. User
> already expects to see copy status printed, so as per user there would be
> no behaviour change.
This is arrant nonsense. It's a behavior change. You can't make it
not that by claiming something abou
On 20 November 2013 18:11, Robert Haas wrote:
> On Wed, Nov 20, 2013 at 4:56 AM, Amit Khandekar
> wrote:
> > So I think it is best to solve this as a different issue, and we should ,
> > for this commitfest, fix only COPY FROM. Once the \COPY existing issue
> is
> > solved, only then we can sta
On Wed, Nov 20, 2013 at 4:56 AM, Amit Khandekar
wrote:
> So I think it is best to solve this as a different issue, and we should ,
> for this commitfest, fix only COPY FROM. Once the \COPY existing issue is
> solved, only then we can start printing the \COPY TO status as well.
I actually think t
On 20 November 2013 17:40, Rajeev rastogi wrote:
> You mean to say that I should change the patch to keep only COPY FROM
> related changes and remove changes related to COPY TO.
>
> If yes, then I shall change the patch accordingly and also mention same
> in documentation also.
>
> Please let me
On 19 November 2013 16:05, Rajeev rastogi wrote:
> On 19 November 2013, Amit Khandekar wrote:
>
> >On 18 November 2013 18:00, Rajeev rastogi
> wrote:
>
> >>On 18 November 2013, Amit Khandekar wrote:
>
> > >>Please find the patch for the same and let me know your suggestions.
>
> >>>In this call
On 18 November 2013 18:00, Rajeev rastogi wrote:
> On 18 November 2013, Amit Khandekar wrote:
>
> >> On 18 October 2013 17:07, Rajeev rastogi
> wrote:
>
> >>From the following mail, copy behaviour between stdin and normal file
> having some inconsistency.
>
> >>
> http://www.postgresql.org/mess
On 18 November 2013, Amit Khandekar wrote:
>> On 18 October 2013 17:07, Rajeev rastogi
>> mailto:rajeev.rast...@huawei.com>> wrote:
>>From the following mail, copy behaviour between stdin and normal file having
>>some inconsistency.
>>
>> http://www.postgresql.org/message-id/ce85a517.4878e
On 18 October 2013 17:07, Rajeev rastogi wrote:
> From the following mail, copy behaviour between stdin and normal file
> having some inconsistency.
>
>
> http://www.postgresql.org/message-id/ce85a517.4878e%tim.k...@gmail.com
>
>
>
> The issue was that if copy execute "from stdin", then it goes
On 21 October 2013 20:48, Robert Haas wrote:
>On Fri, Oct 18, 2013 at 7:37 AM, Rajeev rastogi
>wrote:
>> From the following mail, copy behaviour between stdin and normal file
>> having some inconsistency.
>>
>>
>> http://www.postgresql.org/message-id/ce85a517.4878e%tim.k...@gmail.com
>>
>>
>>
On Fri, Oct 18, 2013 at 7:37 AM, Rajeev rastogi
wrote:
> From the following mail, copy behaviour between stdin and normal file having
> some inconsistency.
>
>
> http://www.postgresql.org/message-id/ce85a517.4878e%tim.k...@gmail.com
>
>
>
> The issue was that if copy execute "from stdin", then it
>From the following mail, copy behaviour between stdin and normal file having
>some inconsistency.
http://www.postgresql.org/message-id/ce85a517.4878e%tim.k...@gmail.com
The issue was that if copy execute "from stdin", then it goes to the server to
execute the command and then server req
37 matches
Mail list logo
