| From: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
|---|---|
| To: | Matt Miller <mattm(at)epx(dot)com> |
| Cc: | PostgreSQL - GENERAL <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Autonomous Transactions |
| Date: | 2005-06-03 20:22:09 |
| Message-ID: | 1117830129.5758.84.camel@state.g2switchworks.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, 2005-06-03 at 15:10, Matt Miller wrote:
> > > a way to enable a function to commit a unit of work that
> > > does not affect the caller's transaction.
>
> > you can establish an independent connection within a function in, say,
> > PL/Perl or PL/Python.
>
> Okay, multiple connections seems to be my best shot. However, I would
> like standard developers to be able to stay in PL/pgSQL and SQL. If
> each of our anonymous transactions needs to be coded in PL/Perl then
> people are not as happy. (Silly people.)
>
> So, can I write some dirty little utility functions (in PL/Perl, C,
> whatever) that a PL/pgSQL caller use to somehow switch connections? The
> way our apps are currently structured I'm picturing that each app's
> logical connection is actually two physical connections: the main thread
> of control happens on one connection, and autonomous transactions happen
> on the other
Is dblink a possible answer? (it's a contrib package.)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Fein | 2005-06-03 21:04:26 | Re: Preventing Multiple Inheritance |
| Previous Message | Matt Miller | 2005-06-03 20:10:29 | Re: Autonomous Transactions |