Re: Nested Transactions, Abort All

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: josh(at)agliodbs(dot)com, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Oliver Jowett <oliver(at)opencloud(dot)com>, Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>, Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>, Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Nested Transactions, Abort All
Date: 2004-07-10 22:00:22
Message-ID: 40F066F6.4020207@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:

>
>The syntax was for support of script languages that don't have
>conditional constructs, like psql scripts, where you want the subxact to
>commit but if it fails, you don't want that to affect the outer
>transaction. Are you saying there are very few cases where you don't
>care if the subxact commits or aborts?
>
>
>
Trying to enable nested transaction on something that has no
conditionals seems strange to me. If you're writing an app so
complicated you so you need NTs, you'd probably not code is as psql script.

BTW, do we have real world examples of apps that are waiting to be
ported to pgsql, needing nested transactions? Looking at the coding
constructions used in those apps could help deciding what semantics
would help them.

Compiere comes to my mind, being oracle now, so they'd probably prefer
named savepoints.

Regards,
Andreas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2004-07-10 22:15:13 Re: Nested Transactions, Abort All
Previous Message Peter Eisentraut 2004-07-10 21:57:46 Re: Nested Transactions, Abort All