On Fri, Apr 22, 2016 at 2:05 AM, Guyren Howe <guyren@xxxxxxxxx> wrote: > If I had the time and money to put together a team to do this, I would start > with the lower-level guts of either Postgres or SQLite (or, heck, MySQL) so > you had a thing that did BTrees and other data structures on disk and > indexes, and provide access to that from a high level, portable and > efficient language. Perhaps Scheme. > > Then you could write a high-level relational logic engine on top of that, in > the high level language, perhaps with the odd bit of C or D or Go for > anything really critical. 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? 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. 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. > 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. > 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. -- Ray Brinzer -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
