[tptacek]

SQL defense isn't a database issue.

The SQL Injection vulnerability is, "user coerces application into submitting an unexpected and unauthorized query".

Blaming the database for that is like blaming the filesystem for pathname injection vulnerabilities.

It could, after all, send a Unix signal to a calling process when a filename contained "..", and demand that the process re-assert it's desire to really reference a different directory.

We may be spiraling here. Parameterized queries are a good thing. I'm glad MySQL has them. I'm not, however, going to wag a finger at MySQL every time someone finds an SQLI vulnerability in an app that uses MySQL, just because 6-7 years ago they didn't have parameterized queries. For one thing, it's not a useful comment (do you want them to implement parameterized queries... again?); for another, it's not particularly valid architectural point; and finally, it's really boring.

[awj]

I think we definitely are spiraling. My argument is about how the stance MySQL took on parameterized queries has affected the product's community. I don't disagree with you on the technical issues. Well, except that providing useful tools to handle SQL defense correctly is a database issue. And pathnames are a read herring, as they are not a transport for data manipulation commands.

I guess part of it is that I'm just done watching various problems with MySQL (transaction support, parameterized queries, subqueries, bizarro query optimization) be given a pass as "not quite MySQL's problem". Maybe I'm just taking that out on this thread.