Re: Nested xact status?
От | Tom Lane |
---|---|
Тема | Re: Nested xact status? |
Дата | |
Msg-id | 5902.1090695230@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Nested xact status? (Alvaro Herrera <alvherre@dcc.uchile.cl>) |
Список | pgsql-hackers |
Alvaro Herrera <alvherre@dcc.uchile.cl> writes: > A previous discarded patch used the static var as means of setting an > abort point when a function was called. The idea was to close all > subtransactions opened within the function, so that the user wouldn't be > presented with subtransactions that the function failed to close. I > think this is still needed, of course. I think that functions should not have the ability to do random things to the subtransaction state, and one of the things that would be right out is exiting at a different subtransaction nest level than they started in. It is not practical for xact.c as such to enforce this; it has to be the responsibility of the functions. In the case of plpgsql this will be probably be enforced by not offering direct access to begin/commit/savepoint/rollback at all. IIRC there is a try/catch-like construct in Oracle pl/sql, and I think what we want to do is offer that syntax as the interface to creating and rolling back subtransactions. In other words, TRY does a SAVEPOINT, successful exit from the TRY block does a RELEASE, and any error inside the TRY block does a ROLLBACK AND RELEASE then transfers control to the CATCH code. We probably want to do something roughly similar in SPI as well, ie, convert the use of savepoints into an implementation detail inside an API that lets you catch errors in SPI commands you execute. I do not want people doing SPI_exec("savepoint") or SPI_exec("rollback") because I don't think it makes any sense. BTW, whether or not you think that ROLLBACK AND RELEASE is needed at the SQL level, it is definitely needed at the implementation level. We don't want useless creation and destruction of a subtransaction every time a plpgsql function catches an error. regards, tom lane
В списке pgsql-hackers по дате отправления: