Re: Status of DBD::mysql with MySQL 5

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/

-- 
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe:    http://lists.mysql.com/[email protected]