MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Kevin Cowley Date:November 11 2004 6:44pm
Subject:RE: Prepared statement for MySQL 4.1
View as plain text  
Re speed benefits

There aren't any - at least not through the C API. It's at least twice as
slow as writing embedded statements and parsing every time. I'm waiting for
them to announce they've fixed it before we consider this route again.

Kevin Cowley
Tel: 0118 902 9099 (direct line)
Email: kevin.cowley@stripped

> -----Original Message-----
> From: Fagyal Csongor [mailto:concept@stripped]
> Sent: 11 November 2004 18:10
> To: 'Mysql ' (E-mail)
> Subject: Re: Prepared statement for MySQL 4.1
> Scott,
> >I've read the article about 'prepared statement' found in MySQL 4.1, and
> am
> >not sure if I understood what 'prepared statement' does and how can it
> >benefit us.  Can anyone elaborate on what 'prepared statement' could do
> with
> >examples where possible?
> >
> >
> >
> In the simplest case, consider this:
> You have an application (say a webpage), which receives user input (say
> a submitted form) which contain an e-mail address that you want to
> insert into a database. Let's say you have this form field in a variable
> called $email:
> Inserting:
> $dbh->do("INSERT INTO mytable (email) VALUES ('$email')");
> Now if you do not verify what is in $email, and the user passes you this
> : notavalidemail@'adress
> you can run into trouble, as the above statement will parse to
> "INSERT INTO mytable (email) VALUES ('notavalidemail@'adress)"
> which is not good, it produces an SQL error because of the "extra" '
> character. You can run into more serious trouble if you get something
> more SQL-like from your form, say "DELETE FROM mytable" or something
> like that ;-)
> Using placeholders take care of quoting, that is, the SQL statement will
> always be valid, at the data will no longer be part of the query. This:
> $dbh->do("INSERT INTO mytable (email) VALUES (?)", undef, $email);
> ...will insert $email into the table without a runtime error (well, it
> is probably not what you want, as you will have an invalid e-mail
> address, but it is still better compared to letting others execute SQL
> commands on your machine...)
> This thing by itself should be enough for anyone NOT to use
> "non-prepared" statements (like many badly written PHP scripts do). But
> there are more things... well, read the article once again, or wait for
> another e-mail on speed benefits :-)
> Regards,
> - Csongor
> --
> MySQL General Mailing List
> For list archives:
> To unsubscribe:

Mulberry Park, Fishponds Road, Wokingham, Berkshire, RG41 2GX
Tel:  +44 (0) 118 902 9000    Fax:  +44 (0) 118 902 9001
This e-mail is confidential and is intended for the use of the addressee only.
If you are not the intended recipient, you are hereby notified that you must 
not use, copy, disclose, otherwise disseminate or take any action based on 
this e-mail or any information herein.
If you receive this transmission in error, please notify the sender
immediately by reply e-mail or by using the contact details above and then
delete this e-mail.
Please note that e-mail may be susceptible to data corruption, interception 
and unauthorised amendment.  Alchemetrics does not accept any liability for 
any such corruption, interception, amendment or the consequences thereof.

Prepared statement for MySQL 4.1Scott Hamm11 Nov
  • Re: Prepared statement for MySQL 4.1Gleb Paharenko11 Nov
  • Re: Prepared statement for MySQL 4.1Mark Maunder11 Nov
  • Re: Prepared statement for MySQL 4.1Fagyal Csongor11 Nov
RE: Prepared statement for MySQL 4.1Scott Hamm11 Nov
RE: Prepared statement for MySQL 4.1Kevin Cowley11 Nov