The MySQL folks have a new tool, MySQL Proxy, which looks like a MySQL server to clients, but actually just passes incoming queries to a user-supplied Lua script which can pass them on to other MySQL servers, process them itself, rewrite queries before passing them on then rewrite the results, etc.
Which is fine in and of itself. I can think of a few uses for such a thing: it'd be great for query logging during debugging, especially when you're examining the interactions of queries from several sources, so just logging on the client wouldn't help. And it'd be useful for distributed database stuff, too.
However, there's a tutorial prominently linked, Getting Started with MySQL Proxy.
And what examples of the uses of the proxy does it give?
- Pass it along unchanged (default)
- Fix spelling mistakes (ever written CRATE DATAABSE?)
- Filter it out, i.e., remove it altogether
- Rewrite the query according to some policy (enforcing strong passwords, forbidding empty ones)
- Add forgotten statements (autocommit is enabled and the user sent a BEGIN WORK? You can inject a SET AUTOCOMMIT = 0 before that)
- Much more: if you can think of it, it's probably already possible; if it isn't, blog about it: chances are that someone will make it happen
Am I the only person who feels that setting up a proxy in front of an SQL server to catch spelling mistakes and semantic errors and Do What I Mean rather than reporting an error so the developer fixes their code will just lead to endless pain... like every past DWIM system? And is an SQL query proxy really the place to enforce strong passwords, as opposed to in the application code or in the database itself?
I think proxies for just about any protocol can be useful, but condoning such practices as listed above is rather irresponsible...