Oops, I just noticed you took us off list. Don't do that, others might have better ideas than me on this. On Thu, Jul 16, 2009 at 7:59 AM, Anj Adu<fotographs@xxxxxxxxx> wrote: > 1. exec Func A > 2. call Func B > 3. Call Func C > > Func A is the outermost control function. > Function B inserts into a set of tables say TableX and TableY > > The inserts into TableX and TableY in Function B are needed before FuncC can > execute. However..if Func C fails..the data in TableX and TableY need not be > rolled back as they are reference tables. We do not want to repeat the > inserts into tableX and tableY if the entire process fails downstream for > some reason. > > Currently..I use PL/Java to simulate an autonomous transaction. But it is a > kludge and PL/Java support for newer JVMs and newer Postgres versions is a > pain to troubleshoot as support is limited. > > > On Wed, Jul 15, 2009 at 10:59 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> > wrote: >> >> On Wed, Jul 15, 2009 at 10:48 PM, Anj Adu<fotographs@xxxxxxxxx> wrote: >> > We have function A calling function B...then function A goes on to do >> > other >> > things (call function C,D) >> > >> > The updates/inserts in function B have to be committed for us to achieve >> > scalability in the process that function A accomplishes (i.e have >> > multiple >> > processes calling the A function run in parallel) >> > >> > Hence...the question on how to commit. >> >> So, are you saying they have to commit, even if they break unique >> constraints, or FKs and such? Or they have to be skipped? I'm not >> sure what you're trying to do still. Maybe some pseudo code that lays >> out what the path is you want to follow on these inserts / updates. > > -- When fascism comes to America, it will be intolerance sold as diversity. -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
