Re: Revisited: Transactions, insert unique.
От | Ross J. Reedstrom |
---|---|
Тема | Re: Revisited: Transactions, insert unique. |
Дата | |
Msg-id | 20000424155306.A5429@rice.edu обсуждение исходный текст |
Ответ на | Re: Revisited: Transactions, insert unique. (Joachim Achtzehnter <joachim@kraut.bc.ca>) |
Ответы |
Re: Revisited: Transactions, insert unique.
("Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>)
Re: Revisited: Transactions, insert unique. (Joachim Achtzehnter <joachim@kraut.bc.ca>) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: