Jochen Wiedmann wrote:
> 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.
>
>
You are right about that. I don't deny there are some benefits in using prepared
statements.
I have been waiting for their implementation in MySQL and I welcome them.
But I must stress that this should not be the default behavior, if it disrupts
existing applications.
>> 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.
Thanks for pointing out that. I missed that method.
Unfortunately, this method doesn't seem to be implemented in DBD::mysql.
When I try to enter OUT or INOUT parameters using bind_param_inout, I get the
error "Output parameters not supported".
Is it truly so or it is perhaps just a documentation problem?
>
>
> Jochen
Cheers
Giuseppe
--
_ _ _ _
(_|| | |(_|>< The Data Charmer
_|
http://datacharmer.blogspot.com/
