Re: pg_restore COPY error handling - Mailing list pgsql-patches

From Stephen Frost
Subject Re: pg_restore COPY error handling
Date
Msg-id 20060202021854.GP4474@ns.snowman.net
Whole thread Raw
In response to Re: pg_restore COPY error handling  ("Andrew Dunstan" <andrew@dunslane.net>)
List pgsql-patches
* Andrew Dunstan (andrew@dunslane.net) wrote:
> Tom Lane said:
> > Also, it might be possible to depend on whether libpq has entered the
> > "copy in" state.  I'm not sure this works very well, because if there's
> > an error in the COPY command itself (not in the following data) then we
> > probably don't ever get into "copy in" state.
>
> Could we not refrain from sending data if we detect that we are not in copy
> in state?

You have to know at that level if it's data you're getting or an SQL
statement though.  SQL statements can fail and things move along
happily.  Essentially what my patch does is detect when a COPY command
fails and then circular-file the data that comes in after it from the
upper-level.  When I started to look at the way pg_restore worked I had
initially thought I could make the higher-level code realize that the
COPY command failed through a return-code and have it not pass the data
down but the return codes didn't appear to be very well defined to
handle that kind of communication...  (As in, it looked like trying to
make that happen would break other things), I can look at it again
though.

    Thanks,

        Stephen

Attachment

pgsql-patches by date:

Previous
From: "Andrew Dunstan"
Date:
Subject: Re: pg_restore COPY error handling
Next
From: Stephen Frost
Date:
Subject: Re: pg_restore COPY error handling