note
mje
<p>I don't believe DBI prevents any SQL. As far as I am aware prepare is a method in the individual DBDs. I don't believe that quote from the DBI pod has anything to do with SQL injection.</p>
<p>Just a few reasons why multiple SQL statements in the same prepare/do call are problematic (or unsupportable as is):</p>
<p>Some DBDs "parse" (mostly roughly) the SQL passed to prepare in order to try and identify placeholders. e.g., DBD::ODBC does this but only because DBI says placeholders may be specified with :name or ? and ODBC itself only defines the latter. I doubt vey much that of those DBDs which parse the SQL to find placeholders many (if any) support recognising N bits of SQL separated by ; So imagine if you did "insert into mytable values(?);insert into mytable values(?)" then any DBD which parses the SQL looking for placeholders may be fooled into thinking you need 2 but in actual fact the database probably executes these sepately.</p>
<p>Generally speaking the databases which support multiple statements in the same prepare run them individually and often there is something required to make it move from one to the next. Imagine 2 select stmts for differing numbers of columns - you need to stop in between them. Imagine an insert followed by another insert (your example), what is to be returned by execute when it is defined as returning the number of affected rows.</p>
<p>Then there are batch statements like execute_for_fetch and execute_array. How is the tuple status to be returned for multiple statements.<p>
<p>There are just too many things which don't fit.</p>
992255
992402