Re: [PATCHES] Continue transactions after errors in psql
От | Tom Lane |
---|---|
Тема | Re: [PATCHES] Continue transactions after errors in psql |
Дата | |
Msg-id | 1814.1114526126@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] Continue transactions after errors in psql (Richard Huxton <dev@archonet.com>) |
Ответы |
Re: [PATCHES] Continue transactions after errors in psql
Re: [PATCHES] Continue transactions after errors in psql Re: [PATCHES] Continue transactions after errors in psql |
Список | pgsql-hackers |
Richard Huxton <dev@archonet.com> writes: > Michael Paesold wrote: >> I just don't see why non-interactive mode does need such a switch >> because there is no way to check if there was an error. So just put two >> queries there and hope one will work? > DROP TABLE foo; > CREATE TABLE foo... Unconvincing. What if the drop fails for permission reasons, rather than because the table's not there? Then the CREATE will fail too ... but now the script bulls ahead regardless, with who knows what bad consequences. I would far rather see people code explicit markers around statements whose failure can be ignored. That is, a script that needs this behavior ought to look like BEGIN; \begin_ignore_error DROP TABLE foo; \end_ignore_error CREATE ... ... COMMIT; where I'm supposing that we invent psql backslash commands to cue the sending of SAVEPOINT and RELEASE-or-ROLLBACK commands. (Anyone got a better idea for the names than that?) Once you've got such an infrastructure, it makes sense to allow an interactive mode that automatically puts such things around each statement. But I can't really see the argument for using such a behavior in a script. Scripts are too stupid. regards, tom lane
В списке pgsql-hackers по дате отправления: