The language itself doesn't matter at all. Everybody would be fine to use some construct like:
Select(args=["name", "id"], from="students")
And maybe "name", "id" and "students" also could be replaced my some reference pointers.
But in case someone really wants to keep the language, you could still do the parsing inside of the lib and thus for example disallow multiple commands in one statement and then only send some binary representation to the server (mostly like Prepared Statements in MySQL). Whereby I think that this step is obsolete and would in any way produce further problems.
Btw., this is not exactly like NoSQL what I am talking about here.
Yes, this looks much like what I want from the outside/usage.
But the implementation of it is actually again the error-prone and slow way to generate a SQL-statement from that, then send that to MySQL and MySQL parses it back to get the original structure.
I actually want to complete avoid that step to generate an SQL statement.
1. It would be much cheaper and faster. Right now, you are: constructing a string first, doing some escaping, then sending this more bloated pure-text query to the server, then parse the SQL language, unescape, convert back into some machine representation. I.e.
a) Most of this extra handling (escaping, string-conversions, parsing) would go away.
b) Less data need to be send around.
2. It would actually make SQL injections impossible and thus solve all these problems.
You've made "SQL injection" impossible by inventing "albertzeyerql", which will inevitably be vulnerable to "AZQL injection". Many of the NoSQL's have similar problems; expect to hear more about them in Blackhat presentations yet to come.
It's not pointless to discuss how query languages can be made simpler to parse and thus less susceptible to injection, but the technique isn't foolproof and is (obviously) expensive; meanwhile, the proper defense against SQLI (being mindful about query inputs, and using the framework to abstract and normalize dynamic queries) is available today and works well.
I am not really talking about a language at all (at least not on a byte-alphabet).
Maybe we misunderstood a bit. For example, take a look at the [new Redis 2.0 protocol](http://redis.io/topics/protocol). In this protocol, injections are simply impossible. This may not be the best example because you don't really have more complicated queries but you could just do the same for tree-like structures.
I think you're wrong, both in your general point and about the possibility about Redis query injection; unfortunately, you're wrong in ways I'm not at liberty to correct. I can only ask that you take my word for it that you need to be as mindful with the code that constructs Redis keys as you do with code that concatenates SQL queries. And, as with SQL, much (perhaps most) production-quality code isn't susceptible to attack; but the lines that are tend to blindside you.
I don't see why you couldn't inject a CR LF? Sure it might not be that dangerous (although it could be depending on what validation the server does on # of args), but you're still modifying the query.
But in case someone really wants to keep the language, you could still do the parsing inside of the lib and thus for example disallow multiple commands in one statement and then only send some binary representation to the server (mostly like Prepared Statements in MySQL). Whereby I think that this step is obsolete and would in any way produce further problems.
Btw., this is not exactly like NoSQL what I am talking about here.