> Why is starting at a low level important? A database is truly relational to > the extent that it implements the relational model. If you don't want the > database to allow tables without keys, or to allow null values, don't let > people create them. If the underlying machinery allows them, that seems like > a mere performance issue; worrying about that from the outset seems like a > perfect example of premature optimization. If PostgreSQL's performance is > acceptable now, why wouldn't it be acceptable with a different interface > language? Agreed. > There are other aspects of what would make a truly relational database, of > course. Codd's 0th rule, for instance, that the "system must be able to > manage data bases entirely through its relational capabilities" to me says > that there should be no data definition language, except as syntactic sugar > for relational operations. So you'd create users (thousands in one command, > if you liked) by adding tuples to a base relation. Yes, maybe, but that makes it not part of the language. You can't apply rule 0 to things like creating a type or operator in a language. > But which things are important? I think a good many of the things one might > would be lower-hanging fruit than that. Just having a clean query language > would alleviate a lot of (my) discomfort. Andl is that. > > I don't know if Postgres exposes the lower-level stuff to plugins or > > not — it would be nice if this could be an alternative query language > > for Postgres itself, > > Well, the parser doesn't, but as best I can tell it's also somewhat loosely > coupled from the system. It doesn't do table access, for instance. It builds > and returns a parse tree. There's no reason you couldn't parse a different > language and return a tree of the same type. Or you could just translate > your input language into SQL, and pass it along to the existing parser. I looked into that, and it's too hard as a starting place. There is too much of the tree and the subsequent query planning that is hooked into specific features of SQL. Instead, Andl generates a small subset of SQL. Once each query has been generated and parsed, the prepared statements can be cached and you get most of the benefits. > > but the assumptions about the two worlds (SQL vs a properly relational > > store) are probably too different. > Are there relational algebra expressions, or other operations necessary to a > truly relational database, which cannot be translated into SQL? I'm not > aware that there are, but I'd be interested to hear of it. If there were, > there's a good chance you wouldn't be able to translate them into the parse > tree, either. Absolutely not. SQL is a (nearly) full implementation of the relational algebra, plus other non-relational stuff. The only thing it really can't handle is a table with no columns! (I have to fake that) Regards David M Bennett FACS Andl - A New Database Language - andl.org -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
