Giuseppe Maxia wrote:
> Moreover, I learned recently, during a presentation by a MySQL developer, that
> the only benefit of prepared statements in MySQL is to have the query on the
> server side, i.e. we only save network bandwidth, but the prepared query is
> evaluated through the query optimizer every time. There is no real "prepared"
> query mechanism that saves optimizer time.
I disagree. The true benefit is that the server *knows* the required
data type, thus knows how to handle the arguments. This is something
that the client can never do and has been a source of confusion from day
1 of the emulated statements.
> The third obstacle to have full development with stored procedures is a mechanism
> to pass parameters to procedures accepting an OUT or INOUT argument. There is no
> standard
> DBI method for this, so I believe that it is time to make a specific extension to
> DBD::mysql.
Wrong. DBI *can* handle IN and OUT variables. See bind_param_inout.
Jochen
