http://www.perlmonks.org?node_id=992395


in reply to Re: Multiple SQL statements in DBI
in thread Multiple SQL statements in DBI

Thanks for your answers, Corion.  I'm using MySQL, but I don't think MySQL is preventing multiple statements, since from the Linux prompt I can echo multiple SQL commands and pipe them to a mysql command and they work.  From looking below at chacham's answer, it looks as if DBI prevents it, which is fine by me.

Replies are listed 'Best First'.
Re^3: Multiple SQL statements in DBI
by moritz (Cardinal) on Sep 08, 2012 at 08:25 UTC

    It's the mysql client library C API that introduces the limitation:

    Executes the SQL statement pointed to by the null-terminated string stmt_str. Normally, the string must consist of a single SQL statement without a terminating semicolon (“;”) or \g.

    Special steps must be taken to allow execution of multiple statements, and seems to be new in version 5.0.

    The Postgresql C API doesn't follow that model, but makes another interesting remark:

    Note however that the returned PGresult structure describes only the result of the last command executed from the string

    which makes it less useful to run multiple statements in a single API call.

      Months later...

      Thanks for that, moritz.  Just noticed your post recently.

      tel2

Re^3: Multiple SQL statements in DBI
by runrig (Abbot) on Sep 07, 2012 at 22:45 UTC

    I don't think DBI prevents anything. It passes the text you give it to the database to parse. If the mysql command line takes multiple statements, then the command line tool is likely parsing separate statements. Likewise, in Oracle, you can pass multiple SQL statements to sqlplus, but not to DBI, because sqlplus does some parsing of its own.

    I do see that the latest version of DBD::mysql supports multiple result sets. You might want to look into that.

      Thanks for that runrig, but why do you say "I don't think DBI prevents anything", when as chacham has pointed out below, the 'DBI documentation states "Multiple SQL statements may not be combined in a single statement handle ($sth), although some databases and drivers do support this (notably Sybase and SQL Server)."'.  To me, that means, regardless of whether the database driver supports it, DBI will prevent it.  Or am I misunderstanding something?

        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.

        Just a few reasons why multiple SQL statements in the same prepare/do call are problematic (or unsupportable as is):

        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.

        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.

        Then there are batch statements like execute_for_fetch and execute_array. How is the tuple status to be returned for multiple statements.

        There are just too many things which don't fit.