Re: storing intermediate results in recursive plpgsql functions - Mailing list pgsql-general

From Gregory Wood
Subject Re: storing intermediate results in recursive plpgsql functions
Date
Msg-id 012f01c1c463$da5c4110$7889ffcc@comstock.com
Whole thread Raw
In response to Re: storing intermediate results in recursive plpgsql functions  (Fran Fabrizio <ffabrizio@mmrd.com>)
List pgsql-general
> >>(apprently sql functions do not automatically end
> >>transactions/release locks like plpgsql functions do)
> >
> > Say what?  There's no difference on that score for any kind of function;
> > none of them end transactions or release locks at exit.
>
> "When a PL/pgSQL function locks a table, the lock is released when the
> PL/pgSQL function returns".

I don't see any way in which that could be a true statement. Which is not to
say that it couldn't be a true statement :)

> "You can't have transactions in PL/pgSQL functions.  Every function is
> executed in one transaction."

This is a true statement (although not worded very clearly). Let me give a
shot at making it more understandable:

You can not start or end a transaction inside a function. The reason for
that is rather simple: PostgreSQL does not support nested transactions.
Since all functions are already wrapped in a transaction, implicit or
explicit, they are already inside a transaction, and therefore can not start
a new transaction. For the same reason, you can not end a transaction
because the function is considered an atomic action.

Greg


pgsql-general by date:

Previous
From: Masaru Sugawara
Date:
Subject: Re: help with getting index scan
Next
From: Bill McGonigle
Date:
Subject: Re: pg_dumpall storing multiple copies of DB's?