If the 'attacker' has access to execute unsafe queries, that is a problem you should address much further up the ladder rather than by adding additional work / responsibility to your DB.
Having said that, there are many development shops that don't have strong database development talent on hand and really treat the database as some black box where to stuff data. In these instances, the database development centric approaches aren't feasible as practical matter. In these cases, I think such a tool can be helpful since at least it gives you the choke point. Where you'd run into issues in this scenario is that this tool requires a learning period to know which queries are good and which aren't. When an application developer changes code, I would imagine that you'd have to address the SQL firewall training as well; a developer that might not be as comfortable developing for the database might not consider that factor and you might get some wonky deployments. I might be missing something on this count only having scanned the docs a bit for this extension.
Exactly. That's the reason why we still see lots of SQL injection attacks and incidents, and the reason why I have created this module. :)
Protection at the application and access layers are always ideal but in that rare case that some major exploit comes along it would be ideal to have extra security one level deeper.
Also, how much overhead does this add? My software is linear (albeit with a fairly large constant) in the size of the input query and constant in the number of queries in the training set.
I doubt that's a problem. Parse analysis won't remove information from the query - otherwise it'll not be available for the actual planning and execution ;)
PostgreSQL's parse analysis keeps a statement structure with token-by-token in the parse tree, and PostgreSQL's query jumbling calculates a hash value from the parse tree.
So, it's possible to find something strange in the statement(s) if someone attempts to cheat.
There's a big argument going on in php-dev right now if php should do some basic, obvious injection protection. Of course that is controversial.