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