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"?
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
Other types of errors, such as the syntax error raised by forgetting the
"GROUP BY" are things that I *want* to be fatal and cause immediate rollback.
In fact, one of issues I have on-and-off with SQL Server is that *nothing* is
fatal by default except not being able to access the databse; as a result,
one needs to manually check for an error after every statement. You can
imagine what happens if you forget one of those checks.
I don't want to go to this by default with postgresql; I still prefer the
default abort transaction. What would be a much easier integration, IMHO,
is offering something like Perl's eval{ } that would allow for special
rollback conditions in an application-defined block.
--
-Josh BerkusAglio Database SolutionsSan Francisco