On 12 March 2014 23:57, Tom Lane Wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 12, 2014 at 12:09 PM, Tom Lane t...@sss.pgh.pa.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
Rajeev rastogi rajeev.rast...@huawei.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:
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,
2014-03-12 7:10 GMT+01:00 David Johnston pol...@yahoo.com:
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
Rajeev rastogi rajeev.rast...@huawei.com 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
David Johnston pol...@yahoo.com 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
On Wed, Mar 12, 2014 at 12:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David Johnston pol...@yahoo.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Mar 12, 2014 at 12:09 PM, Tom Lane t...@sss.pgh.pa.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
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 problem
Rajeev rastogi rajeev.rast...@huawei.com 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
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 correct
Rajeev rastogi rajeev.rast...@huawei.com 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
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
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 ==
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 rajeev.rast...@huawei.com 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
On 27 November 2013 09:59, Rajeev rastogi rajeev.rast...@huawei.com wrote:
On 26 November 2013, Amit Khandelkar wrote:
On 26 November 2013 18:59, Amit Khandekar amit.khande...@enterprisedb.com
wrote:
On 25 November 2013 15:25, Rajeev rastogi rajeev.rast...@huawei.com
wrote:
OK. 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 25 November 2013 15:25, Rajeev rastogi rajeev.rast...@huawei.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.
Now if \copy command is called then, we
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
On 25 November 2013, Amit Khandekar
amit.khande...@enterprisedb.commailto: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
On 22 November 2013 16:14, Rajeev rastogi rajeev.rast...@huawei.com wrote:
On 21 November 2013, Amit Khandekar 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
On 19 November 2013, Amit Khandekar wrote:
On 18 November 2013 18:00, Rajeev rastogi
rajeev.rast...@huawei.commailto: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 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 FROM STDIN. So the
On 21 November 2013, Amit Khandekar
amit.khande...@enterprisedb.commailto: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
On 19 November 2013 16:05, Rajeev rastogi rajeev.rast...@huawei.com wrote:
On 19 November 2013, Amit Khandekar wrote:
On 18 November 2013 18:00, Rajeev rastogi rajeev.rast...@huawei.com
wrote:
On 18 November 2013, Amit Khandekar wrote:
Please find the patch for the same and let me know
On 20 November 2013 17:40, Rajeev rastogi rajeev.rast...@huawei.com 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
On Wed, Nov 20, 2013 at 4:56 AM, Amit Khandekar
amit.khande...@enterprisedb.com 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
On 20 November 2013 18:11, Robert Haas robertmh...@gmail.com wrote:
On Wed, Nov 20, 2013 at 4:56 AM, Amit Khandekar
amit.khande...@enterprisedb.com 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
Amit Khandekar amit.khande...@enterprisedb.com 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
On 21 November 2013 10:13, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Khandekar amit.khande...@enterprisedb.com 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
On 18 October 2013 17:07, Rajeev rastogi 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%tim.k...@gmail.com
The issue was that if copy execute from
On 18 November 2013, Amit Khandekar wrote:
On 18 October 2013 17:07, Rajeev rastogi
rajeev.rast...@huawei.commailto:rajeev.rast...@huawei.com wrote:
From the following mail, copy behaviour between stdin and normal file having
some inconsistency.
On 18 November 2013 18:00, Rajeev rastogi rajeev.rast...@huawei.com wrote:
On 18 November 2013, Amit Khandekar wrote:
On 18 October 2013 17:07, Rajeev rastogi rajeev.rast...@huawei.com
wrote:
From the following mail, copy behaviour between stdin and normal file
having some inconsistency.
On 21 October 2013 20:48, Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 18, 2013 at 7:37 AM, Rajeev rastogi rajeev.rast...@huawei.com
wrote:
From the following mail, copy behaviour between stdin and normal file
having some inconsistency.
On Fri, Oct 18, 2013 at 7:37 AM, Rajeev rastogi
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%tim.k...@gmail.com
The issue was that if copy execute from
36 matches
Mail list logo
