Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52100
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=X4oeGdtAo7AZ5vtvHvINGGJvQoA9JSRWaNqH6tye8r+piovhwu4ur8sSDmV2DhYxMu
         4g+aaWeNidxSXXDhXb+XKa5VIzUI2gSpDwXZ2W8N4GxZCDjecfpOIrAVjoY3I6oOmABK
         mkQFabIrDAZaJ25wzW/eR9V+odBD4NIDiEgTs=
MIME-Version: 1.0
In-Reply-To: <4DBC2D1B.10302@lerdorf.com>
References: <BANLkTimtRdY_+Jj46jFEqkseuz7WD1ZPZQ@mail.gmail.com>
	<4DBC2D1B.10302@lerdorf.com>
Date: Sat, 30 Apr 2011 11:42:03 -0400
Message-ID: <BANLkTimHMj7G5Hx1Ef7eZG48VGR_2CFVNA@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Change Request: Make PDO default to not emulate
 prepared statements for MySQL
From: ircmaxell@gmail.com (Anthony Ferrara)

Well, the benefit to doing it natively would be to prevent SQL
Injection (which is possible now even with PDO's prepared statements).
 As it stands now, it's quite possible to inject when using prepared
statements (easy <=3D 5.3.5, and possible >=3D 5.3.6, depending on
config).  So basically the choice of emulating is drawing the line
saying we care more about performance than we do about security (if
that's how I read the reply).

Anthony

On Sat, Apr 30, 2011 at 11:39 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote=
:
> On 04/30/2011 08:13 AM, Anthony Ferrara wrote:
>>
>> I have already reported this issue on the bug tracker:
>> http://bugs.php.net/bug.php?id=3D54638
>>
>> But I figured it would be good to start a discussion on it here. =A0To
>> me, I consider this a pretty significant issue since it's not possible
>> to do true prepared statements while using PDO. =A0All the code to do so
>> is there (and it does work). =A0But it's just the single flag that
>> defaults emulation to be on that's holding things up.
>>
>> Since it will fallback to using emulation mode if the library or
>> server can't support prepared statements, I don't personally see any
>> issue with changing the default in a point release.
>
> Do you realize why we did this in the first place? The common versions of
> MySQL in use out there are not very clever when it comes to the native
> prepared statement handling. First, there is no prepared statement cache,=
 so
> there is no benefit to doing them natively, but worse, when you use a nat=
ive
> prepared statement you completely miss the query result cache. As a resul=
t
> emulated prepared statements are either the same speed or faster than the
> native ones. Changing this default would result in a performance hit for
> most people. It should be better documented, but that is the only problem=
 I
> see here.
>
> -Rasmus
>