Re: Revisited: Transactions, insert unique.
От | Ross J. Reedstrom |
---|---|
Тема | Re: Revisited: Transactions, insert unique. |
Дата | |
Msg-id | 20000424175235.A7930@rice.edu обсуждение исходный текст |
Ответ на | Re: Revisited: Transactions, insert unique. (Joachim Achtzehnter <joachim@kraut.bc.ca>) |
Ответы |
RE: Revisited: Transactions, insert unique.
("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Re: Revisited: Transactions, insert unique. (Joachim Achtzehnter <joachim@kraut.bc.ca>) |
Список | pgsql-general |
On Mon, Apr 24, 2000 at 02:41:46PM -0700, Joachim Achtzehnter wrote: > > The spirit of the standard comes into play when people who are not > Language Lawyers try to decide how something should work that is not > spelled out explicitly, but where the standard text contains suggestive > statements that imply that the authors assumed something without spelling > it out, because they thought everybody reading the standard would agree on > this as a matter of course. Of course, as soon as somebody comes along who > has some motivation to make a contrary assumption, perhaps to claim > compliance, the fact that the assumption was not spelled out leads to the > kinds of arguments we are having. While I agree with you in theory, that while many more casual standards documents need to be read this way, the SQL standards are highly engineered, passing through multiple national and international committee bodies. Heck, any document that goes to the trouble to define the BNF for <simple Latin letter>, let alone <digit> (section 5.1), clearly aspires to being complete in and of itself. If that is so, omissions are as significant as inclusions. As to other motives, the complete hash that these same bodies have made of the SQL3 spec. leads me to believe that every possible contrary assumption is already present. > > 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. > > This is precisely NOT the game I'm playing! I don't care whether something > is technically 100% compliant or not. I do care a lot about improving a > free software database management system that is in the same league as the > big-name databases. > > The reason I entered this discussion was not to discuss whether PostgreSQLql > is or is not 100% compliant with SQL92. Supporting statement level aborts > is a feature that should be supported at some point, and this talk about > the current practice somehow being compliant with the letter of the > standard doesn't help. But it doesn't hurt (much). This is why we're having this discussion on GENERAL, and not HACKERS: the developers have already agreed that the error system needs an overhaul, mostly to provide the interface writers with consistent error numbers, rather than the current text strings. Inclusion of the ability to ignore some errors will happen. I would not have started this branch of the discussion if the original complaint had not ventured from 'other DBMSs' to 'SQL92 compliant DBMSs' I was _very_ specific that the _only_ thing I disagree with in this is being careful to not provide the enemy with ammunition, as it were, and over interpret the standard to PostgreSQL's detriment. This is why _not_ having this discussion can hurt. In order to aid acceptance of PostgreSQL into many enviroments, being able to play the 'technically SQL92 compliant' card, without having to cross your fingers behind your back, is very important. Heck, I'd be wrestling with Oracle right now, and had a lot less grant money to put into the hardware for my server, if I hadn't been able to play the 'mostly SQL92 compliant, and climbing' card. > > The standard is very explicit about some types of errors, namely > constraint violations, where it says that this must have no effect except > an entry in the diagnostics area. It is precisely these errors where one > would like to be able to continue the transaction. > And this interpretation will guide the developers in _extending_ the standard in a consistent way. I know, because the developers that implemented the constraints for 7.0 used this (and the SQL3 spec) as guides. How's that? Ross P.S. I think we're in (quasi) violent agreement, don't you? -- 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 по дате отправления: