Re: Revisited: Transactions, insert unique.

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(at)rice(dot)edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005