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 pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
