Re: pg_restore COPY error handling
От | Bruce Momjian |
---|---|
Тема | Re: pg_restore COPY error handling |
Дата | |
Msg-id | 200602020254.k122sp126461@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: pg_restore COPY error handling (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-patches |
Stephen Frost wrote: -- Start of PGP signed section. > * 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... Whatever we do is going to be cleaner than looking for "<space>*COPY". > 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. :/ Hence TODO has: o Remove unnecessary function pointer abstractions in pg_dump source code -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-patches по дате отправления: