PL/pgSQL: EXCEPTION NOSAVEPOINT
От | Matt Miller |
---|---|
Тема | PL/pgSQL: EXCEPTION NOSAVEPOINT |
Дата | |
Msg-id | 1123099093.3385.44.camel@dbamm01-linux обсуждение исходный текст |
Ответы |
Re: PL/pgSQL: EXCEPTION NOSAVEPOINT
|
Список | pgsql-patches |
This was motivated by the SELECT INTO EXACT discussion at http://archives.postgresql.org/pgsql-patches/2005-07/msg00559.php. The idea is to allow a PL/pgSQL exception to not automatically rollback the work done by the current block. The benefit is that exception handling can be used as a program flow control technique, without invoking transaction management mechanisms. This also adds additional means to enhanced Oracle PL/SQL compatibility. The patch implements an optional NOSAVEPOINT keyword after the EXCEPTION keyword that begins the exception handler definition. Here is an excerpt from the patched documentation: --------beginning of excerpt----------------------- If NOSAVEPOINT is not specified then a transaction savepoint is established immediately prior to the execution of statements. If an exception is raised then the effects of statements on the database are rolled back to this savepoint. If NOSAVEPOINT is specified then no savepoint is established. In this case a handled exception does not roll back the effects of statements. An unhandled exception, however, will still propagate out as usual, and any database effects may or may not be rolled back, depending on the characteristics of the enclosing block(s). Tip: Establishing a savepoint can be expensive. If you do not need the ability rollback the block's effect on the database, then either use the NOSAVEPOINT option, or avoid the EXCEPTION clause altogether. --------end of excerpt----------------------- Implementation question: In pl_exec.c the new option causes the "BeginInternalSubTransaction," "ReleaseCurrentSubTransaction," and "RollbackAndReleaseCurrentSubTransaction" function calls to be skipped. However, the corresponding "MemoryContextSwitchTo" and related calls are still performed. Should these calls also be dependent on the new option? Would that be more correct, and/or a performance improvement?
Вложения
В списке pgsql-patches по дате отправления: