Skip site navigation (1) Skip section navigation (2)

Re: Recursive Stored Procs?

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: Ben <bench(at)silentmedia(dot)com>
Cc: 'Postgres General' <pgsql-general(at)postgresql(dot)org>
Subject: Re: Recursive Stored Procs?
Date: 2003-03-29 20:13:47
Message-ID: 20030329120758.V13370-100000@megazone23.bigpanda.com (view raw or flat)
Thread:
Lists: pgsql-general
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).


In response to

pgsql-general by date

Next:From: Jean-Luc LachanceDate: 2003-03-29 21:00:02
Subject: Re: XOR operator.
Previous:From: BenDate: 2003-03-29 19:43:16
Subject: variable-count stored proc arguements?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group