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@xxxxxxxxxxxx> To: "Craig Bryden" <postgresql@xxxxxxxxxxxx> Cc: "pgsql" <pgsql-general@xxxxxxxxxxxxxx> Sent: Tuesday, July 12, 2005 7:43 PM Subject: Re: Transaction Handling in pl/pgsql > "Craig Bryden" <postgresql@xxxxxxxxxxxx> 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 > > ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
