PL/pgSQL: EXCEPTION NOSAVEPOINT

From: Matt Miller <mattm(at)epx(dot)com>
To: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: PL/pgSQL: EXCEPTION NOSAVEPOINT
Date: 2005-08-03 19:58:13
Message-ID: 1123099093.3385.44.camel@dbamm01-linux
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers 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?

Attachment Content-Type Size
exception_nosavepoint.patch text/x-patch 10.3 KB

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2005-08-03 20:25:30 Re: PL/pgSQL: EXCEPTION NOSAVEPOINT
Previous Message Aaron Harsh 2005-08-03 19:35:26 oids and pg_class_oid_index constraint violations

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-08-03 20:25:30 Re: PL/pgSQL: EXCEPTION NOSAVEPOINT
Previous Message Luca Stancapiano 2005-08-03 16:57:36 ssl problem on postgres 8.0

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2005-08-03 20:25:30 Re: PL/pgSQL: EXCEPTION NOSAVEPOINT
Previous Message Michael Fuhr 2005-08-03 15:32:23 ECPG ignores SAVEPOINT if first statement of a transaction