Added to TODO:
o Allow COPY to report errors sooner
http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> Hi,
>
> I notice
* Martijn van Oosterhout ([EMAIL PROTECTED]) wrote:
> On Wed, Apr 16, 2008 at 05:22:17PM -0400, Tom Lane wrote:
> > Even if we had some way of letting the application notice that the copy
> > had already failed, I don't see that psql could do very much with it,
> > at least not for COPY FROM STDIN.
On Wed, Apr 16, 2008 at 05:22:17PM -0400, Tom Lane wrote:
> I dunno about "intentional", but the API exposed by libpq for COPY
> doesn't really permit any other behavior: you push all the data and
> then look to see if it worked or not.
Oh? I expected the PQputData would return -1 as stated by the
Tom Lane wrote:
> We could possibly fix libpq to start dropping the data on the floor
> if it sees an error reply already pending, but that's only going
> to be an incremental change.
I think this incremental change makes a lot of sense. What point is
there in transmitting the data over the netw
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> I notice that while doing bulk-loads that any errors detected by the
> backend arn't noticed by libpq until right at the end. Is this
> intentional?
I dunno about "intentional", but the API exposed by libpq for COPY
doesn't really permit any oth
Martijn,
* Martijn van Oosterhout ([EMAIL PROTECTED]) wrote:
> Is there anything that can be done? I've tried putting in
> PQconsumeInput in places but it doesn't appear to help.
I certainly hope something can be done, I've noticed this exact same
issue myself and it's very annoying. I've resort
Hi,
I notice that while doing bulk-loads that any errors detected by the
backend arn't noticed by libpq until right at the end. Is this
intentional? Looking at the code we have this comment in putCopyData:
/*
* Process any NOTICE or NOTIFY messages that might be pending in the
* input buf
