As an academic exercise it would be interesting to try and create the *next* RDBMS query language. In a production environment I do think the idea is crazy.
I've got a little experience with this. Interbase used to support a more procedural query language called GDML (along with SQL). I used it in a production system. I had a reason, which was that it supported multi-threading (like SET CONNECTION does in more recent SQL.) In retrospect, it was a lousy decision. First off, it wasn't all that popular, and Borland dropped support for it. So much for maintenance. I was one of very few people who bothered to learn it. Great job security, if you want to maintain a legacy system as a job your locked into. Trained programmers, evolving capability, and a helpful user community was nonexistent. You got a problem? You're on your own. Rick [EMAIL PROTECTED] wrote on 03/31/2005 07:46:02 PM: > I came across an old RDBM called Business System 12 > (http://www.mcjones.org/System_R/bs12.html) a few days ago. It seemed > to have a much simpler method of specifying queries - more similar in > style to relation algebra than SQL. For example, some example code > might look like this. > > view = join(rel_1, rel_2) --assertains join criteria > based on primary keys > filtered_view = select(condition_list, view) > result = project(attribute_list, filtered_view) > > Ignoring for a minute that SQL is the accepted method of talking to > databases, and also acknowledging that SQL may be more expressive than > relational algebra, I wondered if it would be possible to extend > Postgresql to allow non-sql interfaces to simple database services. > > I suppose it would be possible to convert statements like those above > into their SQL equivalent before passing them to an existing driver, but > from reading the docs, it seems that dbmses usually do these types of > operations once they have parsed the SQL anyway. > > I'd be interested to hear your thoughts on the subject whatever they > are. Critical comments are particularly welcome (they might be quite > useful for getting this stupid idea out of my head ;-)). > > Regards, > Andy > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
