Re: 4 the FAQ: Are Commercial DBMS Truly Relational?

From: Laconic2 <laconic2_at_comcast.net>
Date: Sat, 9 Oct 2004 14:15:18 -0400
Message-ID: <UOqdnTl6jvdUt_XcRVn-hw_at_comcast.com>


"Marshall Spight" <mspight_at_dnai.com> wrote in message news:WLT9d.150812$wV.77513_at_attbi_s54...

> I think Mr. Pascal would probably take issue with the phrase
> "acceptable error." He's something of an absolutist.
>
It's OK to be an absolutist. Until the first time you are wrong. And, if you're human, that won't be long.

> While I'm somewhat disenchanted with Pascal &co. lately,
> there is something to be said about a "no compromises" attitude.
> But this most relevant to language designers. One point they make
> that I really buy is that a more regular language would be
> easier to use and easier to optimize.

Hmmm.... SQL as a language suffers from a lot of defects. Aside from the conflicts between the SQL data model and the RDM, there are numerous little bits of wretched syntax in the language, as a language.

Just for the sake of example, the language would be cleaner if you had to enclose lists of things separated by commas in parentheses. As in:

SELECT DISTINCT (expr1, expr2, expr3, ...) FROM (source1, source2, source 3,....)
WHERE (predicate)
GROUP BY (item1, item2, ...)
HAVING (predicate)
ORDER BY (sortkey1, sortkey2, sortkey3,...)

None of the parentheses above are required in current SQL, and some of them aren't even allowed. I would like to see them all required.

OK, I admit that those parentheses would be hard to type and hard to read, and people would probably get more errors. Someone could write a UI that helps you get it right...

But it would make it possible to write a parser with user friendly error messages, which it is currently not possible to do.

Also, it might be worthwhile to decide whether SQL is a "data sublanguage" or "another programming language". Received on Sat Oct 09 2004 - 20:15:18 CEST

Original text of this message