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 <= 5.3.5, and possible >= 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 <ras...@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=54638 >> >> But I figured it would be good to start a discussion on it here. To >> me, I consider this a pretty significant issue since it's not possible >> to do true prepared statements while using PDO. All the code to do so >> is there (and it does work). But 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 native > prepared statement you completely miss the query result cache. As a result > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
