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 Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])