Chris Bitmead writes:
> Is this behaviour some kind of standard? Can it be changed?
In the past the answer to the question "Does a statement-level error
warrant a transaction abort?" has usually hinged on the interpretation of
the following clauses of the SQL92 standard.
3.3.4.1 Exceptions
The phrase "an exception condition is raised:", followed by the
name of a condition, is used in General Rules and elsewhere to
indicate that the execution of a statement is unsuccessful, ap-
plication of General Rules, other than those of Subclause 12.3,
"<procedure>", and Subclause 20.1, "<direct SQL statement>", may
be terminated, diagnostic information is to be made available,
and execution of the statement is to have no effect on SQL-data or
schemas.
4.28 SQL-transactions
[...]
The execution of a <rollback statement> may be initiated implicitly
by an implementation when it detects unrecoverable errors. When
such an error occurs, an exception condition is raised: transaction
rollback with an implementation-defined subclass code.
So essentially we classify all errors as unrecoverable, which is certainly
dumb, but legal. But then we still don't comply because we don't execute
the rollback automatically but instead hang in some sort of "invalid"
state.
There is certainly big demand for getting rid of this restriction though,
but the code changes could end up being very extensive.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
