OK. I have read that. The part that sticks out is "A block containing an
EXCEPTION clause is significantly more expensive to enter and exit than a
block without one. Therefore, don't use EXCEPTION without need. ".
Performance is paramount to me.
If I ommit the EXCEPTION clause will all the statements still be rolled back
if an error occurs?
Thanks
Craig
----- Original Message -----
From: "Douglas McNaught" <doug@mcnaught.org>
To: "Craig Bryden" <postgresql@bryden.co.za>
Cc: "pgsql" <pgsql-general@postgresql.org>
Sent: Tuesday, July 12, 2005 7:43 PM
Subject: Re: [GENERAL] Transaction Handling in pl/pgsql
> "Craig Bryden" <postgresql@bryden.co.za> writes:
>
> > I am trying to get a better understanding of how transactions work in
> > pl/pgsql functions. I found the following text in the help:
> > "It is important not to confuse the use of BEGIN/END for grouping
statements
> > in PL/pgSQL with the database commands for transaction control.
PL/pgSQL's
> > BEGIN/END are only for grouping; they do not start or end a transaction"
> > but I am still a bit confused.
> >
> > Suppose I have a function that will be called from an application. Will
all
> > the statements in the function be rolled back if the last one generates
an
> > exception? or do I need to add code to a function to make that happen?
>
> Read up on how in-function exception handling and savepoints interact
> for pl/pgsql in 8.0:
>
>
http://www.postgresql.org/docs/8.0/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING
>
> For previous versions (7.X), the whole thing will be rolled back if
> anything in the function throws an exception.
>
> -Doug
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
>
