Re: storing intermediate results in recursive plpgsql

On Tue, 5 Mar 2002, Tom Lane wrote:

> Fran Fabrizio <ffabrizio(at)mmrd(dot)com> writes:
> > If that's the case, then this is the second time in a week I've found
> > huge errors in this darn PostgreSQL Developer's Handbook I bought. I'm
> > coming very close to tossing this thing in the garbage.
>
> > "When a PL/pgSQL function locks a table, the lock is released when the
> > PL/pgSQL function returns".
>
> This is bogus...
>
> > "You can't have transactions in PL/pgSQL functions. Every function is
> > executed in one transaction."
>
> This is perfectly true: the transaction in which the calling query is
> contained also contains the operations executed in the called function.
> However, evidently the context misled you to think it meant that the
> function has its own transaction.

According to our docs:

----------
If you do a LOCK TABLE in PL/pgSQL, the lock will not be released until
the calling transaction is finished.

and

You also cannot have transactions in PL/pgSQL procedures. The entire
function (and other functions called from therein) is executed in a
transaction and PostgreSQL rolls back the results if something goes
wrong.
----------

So if the function is executed in a transaction and the transaction
ends when the function does, doesn't that mean the lock is released
when the function ends?

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev(at)michvhf(dot)com http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================