Re: pg_restore COPY error handling
От | Stephen Frost |
---|---|
Тема | Re: pg_restore COPY error handling |
Дата | |
Msg-id | 20060202025354.GR4474@ns.snowman.net обсуждение исходный текст |
Ответ на | Re: pg_restore COPY error handling (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: pg_restore COPY error handling
|
Список | 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
Вложения
В списке pgsql-patches по дате отправления: