Re: savepoint improvements
От | Simon Riggs |
---|---|
Тема | Re: savepoint improvements |
Дата | |
Msg-id | 1169481166.3776.333.camel@silverbirch.site обсуждение исходный текст |
Ответ на | Re: savepoint improvements (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: savepoint improvements
|
Список | pgsql-hackers |
On Mon, 2007-01-22 at 10:46 -0500, Tom Lane wrote: > "Merlin Moncure" <mmoncure@gmail.com> writes: > > On 1/22/07, Simon Riggs <simon@2ndquadrant.com> wrote: > >> Could you post an example, just so we're all clear what the problems > >> are? I thought I understood what you are requesting; I may not. > > > ok, > > > The short version is I would like the ability to run some sql commands > > and recover the transaction if an error occurs. > > I'm getting tired of repeating this, but: neither of you have said > anything that doesn't appear to me to be handled by ON_ERROR_ROLLBACK. > What exactly is lacking in that feature? Sorry for not replying to your other post. ON_ERROR_ROLLBACK doesn't do the same thing, thats why. It shuts out the noise messages, true, but it doesn't re-execute all of the commands in the transaction that succeeded and so breaks the transaction, as originally coded. BEGIN; stmt1; stmt2; <-- error stmt3; COMMIT; results in stmt3 completing successfully even though stmt1 and stmt2 do not == broken script. The behaviour we've been discussing is when stmt2 fails, to allow stmt3 to be submitted, so that at commit, stmt1 and stmt3 effects will be successful *if* the user wishes this. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: