Re: Dreaming About Redesigning SQL

From: Seun Osewa <seunosewa_at_inaira.com>
Date: 4 Oct 2003 08:49:08 -0700
Message-ID: <ba87a3cf.0310040749.6fbd37f4@posting.google.com>

Replies to this Thread From PostgreSQL Hackers

mascarm_at_mascari.com (Mike Mascari) wrote in message news:<3F7E3F49.2040709_at_mascari.com>... I read the Third Manifesto. There are many ideas in the TTM that have strong arguments, although I most confess I haven't read any critiques. A few (of many) points:

Strict adherence to the relational model, where all of SQL's short-comings are addressed:
No attribute ordering
No tuple ordering (sets aren't ordered)
No duplicate tuples (relations are sets)
No nulls (2VL sufficient. Missing information is meta-data)
No nullogical mistakes (ex: SUM of an empty relation is zero, AVG is an error)
Generalized transitive closure
Declared attribute, relation variable, and database constraints, including transition constraints
Candidate keys required (this has positive logical consequences for the DBMS implementor)
Tuple and relation-valued attributes
No tuple-level operations

a bunch more...

2) The query language should be computationally complete. The user should be able to author complete applications in the language, rather than the language being a sublanguage. This reverses Codd's query sublanguage proposed in "A Relational Model of Data for Large Shared Data Banks"

http://www.acm.org/classics/nov95/s1p5.html

<sarcasm>
Thanks ACM for just putting part of the paper on-line, complete with broken links and spelling errors!
</sarcasm>

3) The language (a D implementation) would ensure a separation between the logical design of the application and the physical implementation. The programmer should think in terms of the evaluation of relational algebraic expressions, not manipulating physical records in disk blocks in a file.

4) The type system should separate the actual, internal representation from the possible representation, of which there might be many. For example, a POINT may be internally expressed in cartesian coordinates but may supply both polar and cartensian THE_ operators.

5) The type system should implement D & D's view of multiple inheritance, where read-operators are inherited but write-operators aren't. This eliminates the "Is a Circle an Ellipse?" dilemma imposed by C++, for example. IOW, in a "D" language, a Circle is an Ellipse.

They reject Stonebreaker's ideas of OIDs and relation variable inheritance, which of course, are in PostgreSQL.

It's a very provocative read. At a minimum, one can learn what to avoid with SQL. The language looks neat on paper. Perhaps one day someone will provide an open source implementation. One could envision a "D" project along the same lines as the same sort of project that added SQL to Postgres...

But I'd rather have PITR :-)

Mike Mascari
mascarm_at_mascari.com

hannu_at_tm.ee (Hannu Krosing) wrote in message news:<1065254989.2746.4.camel_at_fuji.krosing.net>...

Mike Mascari kirjutas L, 04.10.2003 kell 06:32:
>
> 2) The query language should be computationally complete. The user
> should be able to author complete applications in the language, rather
> than the language being a sublanguage.

To me it seems like requiring that one should be able to author complete programs in regex.

Yes, when all you have is a hammer everything looks like a nail ;)

Hannu

Received on Sat Oct 04 2003 - 10:49:08 CDT