Re: nested transactions

From my SQL Server days, I remember the nested transactions feature being one that I spent a lot of time trying to undo. As I recall, if you had a trigger that called a function (stored procedure) and the SP threw an error, the trigger would merrily go about its business as if nothing had happened. You had to encircle each sql statement with error trapping code, and if one was found, see how far into the nest of transactions you were, and roll back the transaction (if you were in one) then set the return code to let all the higher level transactions know something went wrong, so each of them could decide whether to roll back.

If the error checking was in the DBMS (instead of having to be written by hand) and the nested transactions rolled each other back if an error was detected, wouldn't we be back where we are now?

What's the benefit?

- Ian

>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 04/22/02 03:11PM >>>
Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> writes:
> "Steven D. Arnold" <stevena(at)neosynapse(dot)net> wrote:
>> Also, are nexted transactions "on the board," and if so, when/what
>> release are they planned for?

> They're on the TODO list, but AFAIK no one has volunteered to implement
> them yet.

Steven should probably be warned that this is a "don't hold your breath"
kind of thing. AFAICS, nested transactions would require a huge amount
of work by very knowledgeable hackers (for example, looking at nearly
every error-exit condition in the backend, to see if it's going to cause
a problem with continuing the current transaction). The small number
of people who could do it have other priorities.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)