Josh Berkus wrote: > Bruce, > > > > So, whatever "error handling mode" conveniences we wish to put in should > > > be put in on the client side. > > > > Added to TODO: > > > > ????????* Use nested transactions to prevent syntax errors from aborting > > ???????? ?a transaction > > Hmmm .... I'm not sure how you arrived at this wording for the TODO. How are > we defining a "syntax error"?
Parser error, I would say. Misspelling a table name, perhaps. Not sure on that one, but clearly this opens a can of worms we will have to deal with someday. > I write a lot of procedures for T-SQL with error-controlled rollback, and a > few for Oracle. I can tell you that all of the errors which I anticipate > for, and thus do not abort the operation when I encounter, fall into one of > these types: > 1) Constraint conflict: duplicate key. > 2) Constraint/Data Type conflict: bad value format > 3) Duplicate object name > 4) Object not found > 5) Lock conflict Certainly this will never be the default. My guess is that for these cases, you will have to code the transaction/subtransaction yourself in your script. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
