The SQL standard already defines an API call SQLExecDirect() which prepares and executes a statement in one round-trip. You can't execute the statement after executing it in this way.

SQLExecDirect() does not support some statements (CONNECT, COMMIT, FETCH, CLOSE, etc.). But it's meaningless to add parameters to these types of statements anyway.

MySQL can't prepare DDL statements, but this is a failure of MySQL, not the standard. However, I would say it's a minor issue, because one shouldn't need to add parameters to a CREATE TABLE statement either.

The fact that MySQL has failed to implement the API well does not invalidate the API. The solution shouldn't be to invent new non-standard functionality when a standard solution exists.

Er, the second sentence above should be "You can't execute the statement _again_ after executing it in this way."

Somehow we are not communicating well with each other. Again my point is that I rarely need to execute the same statement twice in a request and therefore using PS makes no sense just to get SQL injection protection because of the fact that DB roundtrips are expensive (a fact that has been well established).

I will say no more, because whenever I add other minor issues to how PS work or not work that have further negative effects, you seem to choose to focus on these aspects instead of the key aspect (that I tried to highlight as the key aspect in all of my previous posts).

Er, my last comment seems to have gone AWOL.

Has anyone tried connecting to MySQL via PDO ODBC?

Viewing queries sent in MySQL-Proxy..

$pdo = new PDO('odbc:DRIVER={MySQL ODBC 5.1 Driver};SERVER=localhost;PORT=4040;DATABASE=wikidb;USER=root;');
$q = $pdo->prepare('SELECT * FROM page p WHERE page_title = :title');
$q->bindValue('title', 'Main_Page', PDO::PARAM_STR);
$q->execute();

Is executed as

SELECT * FROM page p WHERE page_title = _latin1'Main_Page'

So seems the ODBC driver is doing the "preparing".

No, it's PDO that is interpolating your parameter value into the query. It does this to emulate named parameters (e.g. :title), which MySQL doesn't support natively.

@Lukas:
I understand your point -- you want a new extension in SQL for immediate single-time execution of a SQL statement, _with_ parameters. And somehow you reason that prepared statements are "no longer relevant" (your words).

My point is, there is no need for an extension to SQL, because SQL already defines a method that is exactly what you are asking for.

I disagree with you that prepared statements are no longer relevant. I grant that prepared statements may result in anomalies when used inappropriately. But the same could be said for practically any feature of any programming language. Would it be novel to suggest that developers should know how to use their tools correctly?

@Bill Karwin, Actually its both. PDO rewrites queries from :name to ? if the PDO knows the DB doesn't support :name. Then that is handed to ODBC which does the preparing. Its two seperate steps. Hence why the _latin string charset specifier appears in the generated the SQL.

If add the CHARSET=utf8 parameter to the PDO connection string, to tell the ODBC driver your working with utf8, it then omits the charset specifier.