Advanced Minds

 Prepared statements have been supported by MySQL since the production release of 4.1 in late 2004.  Support for the 4.1 release ended 15 months ago.  I don't think it's appropriate to support anything older than that, and if supporting 4.1 means a less secure or less maintainable driver, I don't see why you'd go out of your way to support even that. I don't think it's feasible to _replace_ current direct queries with prepared ones, because of user supplied select clauses. They will either work with direct queries or with prepared ones, not both. Synthesized queries can still fail, e.g. if the name field is '?'. In the patch, prepared statements are attempted for the main SELECT query, not password change nor enumeration. However, I also made a number of changes: * patch 2007-10-02 07:55:07 by Anton Dobkin moved at session initialization; * in auth_mysql_setpass() removed test against control chars in the new password, and replaced ad hoc escape function; * Change get_localpart(); * use mysql escape function also in a number of other places; the MySQL team took years to get it straight... With that, I could get a line of Apr 16 20:49:58 north authdaemond: Authenticated: sysusername=<null, sysuserid=117, sysgroupid=117, homedir=/mail/tana.it/hasthem, address= has the quotes @tana.it, fullname=<null, maildir=<null, quota=<null, options=disableimap=0,disablepop3=0,disablewebmail=0,sharedgroup= For non-prepared queries, the patched program produces a snippet like     WHERE addr = ' has the quotes @tana.it' while the old get_localpart() only copies the inner quotes, unescaped. Without user supplied select clause, and no funny fields, I saw a performance gain of about 50%, as the average time per query dropped from 333~345 to 143~154 usecs on an idle new server I'm setting up. However, queries are not cached for prepared statements, and MySQL docs suggest to experiment both methods. To select different users for each call I used a slightly modified version of authtest that I just copied to http://www.tana.it/sw/courier-utils/testmailuser.c

This is a MIME GnuPG-signed message.  If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. The Internet standard for MIME PGP messages, RFC 2015, was published in 1996. To open this message correctly you will need to install E-mail or Usenet software that supports modern Internet standards.

On the other hand, we cannot guarantee that prepared statements work in *all* cases. Why not?

On the other hand, we cannot guarantee that prepared statements work in *all* cases. Why not? Some forms of queries don't work. E.g. you cannot have parameters markers on bot sides of an comparison, as in WHERE ? = ? , for mysql_stmt_prepare() wouldn't be able to infer operand types; and you cannot append a further statement, separated with a semicolon. I also read something obscure about stored procedures. That's in addition to quoting: WHERE '$(local_part)' = ... works when interpreted, while WHERE $(local_part) = ... works when prepared (as WHERE ? = ... .) The patch does not work even with innocent question marks, like e.g. MYSQL_NAME_FIELD = IFNULL(user_name, 'uh?'). That's just laziness, and can be amended...