Thread: Recursive Stored Procs?

Recursive Stored Procs?

From
Ben
Date:
Does postgres support recursive stored procs? I thought I remember
reading in the docs a while back that it didn't, but now I can't find
any mention one way or another.

If they are supported, how do transactions work? For example, say A
calls B followed by C, and C has an error. I assume C is automatically
aborted. While A can detect if C failed and also abort, what about the
changes B made? If the call to A starts the transaction and the exit of
A commits or aborts, then that's cool, but if each call gets its own
transaction, that would make things difficult.


Re: Recursive Stored Procs?

From
Stephan Szabo
Date:
On 29 Mar 2003, Ben wrote:

> Does postgres support recursive stored procs? I thought I remember
> reading in the docs a while back that it didn't, but now I can't find
> any mention one way or another.

Umm, I think there may have been problems in the past, but I think it
works now (at least in some cases).

> If they are supported, how do transactions work? For example, say A
> calls B followed by C, and C has an error. I assume C is automatically
> aborted. While A can detect if C failed and also abort, what about the
> changes B made? If the call to A starts the transaction and the exit of
> A commits or aborts, then that's cool, but if each call gets its own
> transaction, that would make things difficult.

The statement containing the call to A is in a transaction.  C's error
will abort that transaction (so for example if it's in an update and the
100th call to A calls C and errors all of the update is rolled back). If
we get nested transactions at some point the behavior would depend if the
functions declare transactions (I'd assume the default would be no, and
you'd have to do something to make a sub transactoin).