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
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 |