Re: storing intermediate results in recursive plpgsql functions

Vince Vielhaber  writes:
> 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?

But the transaction *doesn't* end when the function does.

The function must have been called from some SQL query (eg, a SELECT)
and there is an explicit or implicit transaction wrapped around every
query issued by an application.  The earliest the lock can possibly be
released is when the current application-given query ends.  If the query
is inside an explicit BEGIN/COMMIT block then the lock will be held till
you COMMIT or ROLLBACK.

Feel free to propose better wording for that part of the plpgsql docs...

			regards, tom lane