| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | peter(at)retep(dot)org(dot)uk |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: SQL-Invoked Procedures for 8.1 |
| Date: | 2004-09-24 13:06:50 |
| Message-ID: | 87sm97ak9h.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Mount <peter(at)retep(dot)org(dot)uk> writes:
> Tom Lane wrote:
>
> >One interesting point is whether it's possible for one procedure to call
> >another, and if so what that means for the semantics. Is the inner
> >procedure allowed to commit a transaction started by the outer one?
>
> Usually yes a procedure can call another, and it's extremely useful to do so.
> I'm not so sure about the semantics with transactions, but personally I
> wouldn't like to see a procedure be able to commit the transaction of it's
> caller.
From the quote from the spec referred to earlier it seems the spec anticipates
that by default it wouldn't be able to. At least not able to commit refer to
savepoints from its caller. Presumably that extends to transactions.
However it did provide a way to declare a procedure that could refer to
savepoints from its caller. Conceivably that extends to the overall
transaction as well.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hicham G. Elmongui | 2004-09-24 13:22:29 | planner & target lists |
| Previous Message | Maarten Boekhold | 2004-09-24 12:56:05 | Re: SQL-Invoked Procedures for 8.1 |