Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> This is not super surprising because the original design approach for
>> pg_restore was "bomb out on any sort of difficulty whatsoever". That
>> was justly complained about, and now it will try to keep going after
>> SQL-command errors ... but it sounds like the COPY-data processing
>> part didn't get fixed properly.
> Exactly so. Possibly because it appears to be non-trivial to detect
> when it was a *COPY* command which failed (to differentiate it from some
> other command). What I did was check for '<whitespace>COPY'. I'd be
> happy to change that if anyone has a better suggestion though.
ISTM you should be depending on the archive structure: at some level,
at least, pg_restore knows darn well whether it is dealing with table
data or SQL commands.
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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
