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

From Stephen Frost
Subject Re: pg_restore COPY error handling
Date
Msg-id 20060202025354.GR4474@ns.snowman.net
Whole thread Raw
In response to Re: pg_restore COPY error handling  (Stephen Frost <sfrost@snowman.net>)
Responses Re: pg_restore COPY error handling  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
* Stephen Frost (sfrost@snowman.net) wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > 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.
>
[...]
> I'd be happy to work this up, and I think it would work, but it seems
> kind of ugly since then we'd have ahwrite and ahprintf returning error
> codes which in 99% of the cases wouldn't be checked which doesn't seem
> terribly clean. :/

Looking at this again, I'm not 100% sure it'd work quite that cleanly.
I'm not sure you can just skip that PrintTocDataPtr call, depending on
the how the input is coming in...  There might be a way to modify
_PrintData (in pg_backup_custom.c, and the others, which is what is
the function behind PrintTocDataPtr) to somehow check an AH variable
which essentially says "the data command failed, just ignore the input",
and we'd need to set the AH variable somewhere else, perhaps using the
return value setup I described before...

All of this is sounding rather invasive though.  I have to admit that
I'm not exactly a big fan of the pg_dump/pg_restore modular system. :/

    Thanks,

        Stephen

Attachment

pgsql-patches by date:

Previous
From: Stephen Frost
Date:
Subject: Re: pg_restore COPY error handling
Next
From: Bruce Momjian
Date:
Subject: Re: pg_restore COPY error handling