On Mon, Apr 24, 2000 at 01:10:55PM -0700, Joachim Achtzehnter wrote:
>
> Perhaps, you can make the argument that an automatic rollback in all error
> situations is compliant by claiming that all errors are unrecoverable. In
> my view this is definitely against the spirit of the standard. As you said
> yourself, all big-name databases behave according to my interpretation,
> hence it is understandable that the authors of the standard didn't see a
> need to spell this out more explicitly.
>
Joachim -
I see you haven't done much Language Lawyering, have you? There is no
such thing as the 'spirit' of the standard, only the written document.
;-) This is exactly my argument, with regard to errors and the standard:
_which_ errors are considered unrecoverable is not spelled out in the
standard, therefore, it is implementation defined. The fact the the
definition chosen by postgresql is inconvenient for users of the database
is, I agree, unfortunate, but it doesn't stand in the way of us claiming
compliance, which is the name of the game for these sort of standards.
Note that postgres is careful not to _automatically_ rollback: the
standard (as you quoted) indicated only certain conditions that allow for
an implicit rollback of that sort. Postgres just won't let you do anything
else in the current transaction. Yes, it's splitting hairs, but if you dig
into any of the 'bigname' DBs, you'll find similar split ends. Often, the
end is able to be split, i.e. the language in the standard is ambigious,
_because_ the commercial DB had representitives on the committee, making
sure the standard didn't get too far from their exisiting implementation.
I might even argue that the original definition was a good, conservative
choice, for the early days of postgres as a research database: you
_know_ people have been messing with the server code, and if something
throws an error, bailing out is the safest course. Now that the core
developers have done an amazing job at cleaning up and stabilizing
the code, a more relaxed attitude toward certain classes of errors is
desirable. There's been a fair amount of discussion about cleaning up
(defining!) the error codes returned, as well, so a complete overhaul
may be in the works. That'd clearly be the time to fix this up. I beleive
it's already on the TODO list.
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
