Le jeudi 16 octobre 2014 à 18:10 +0200, Ferenc Kovacs a écrit : > On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > > > On 10/16/2014 04:27 AM, Ferenc Kovacs wrote: > > > On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara <ircmax...@gmail.com> > > > wrote: > > > > > >> Hello all, > > >> > > >> I raised this topic on list over a year ago ( > > >> http://marc.info/?l=php-internals&m=130417646507744&w=2 ). It was > > >> determined that it wasn't time yet to disable prepared statement > > >> emulation for MySQL yet. However, Rasmus did mention that it was a > > >> possibility for 5.4 ( > > >> http://marc.info/?l=php-internals&m=130418875017027&w=2 ). Since that > > >> ship has sailed, I submitted a pull request for trunk to change the > > >> default value of prepared statement emulation for MySQL. > > >> > > >> https://github.com/php/php-src/pull/108 > > >> > > >> https://bugs.php.net/bug.php?id=54638 > > >> > > >> Does this need to be an RFC (should I draft one)? Or can it just be > > >> pulled as-is? > > >> > > >> Thanks, > > >> > > >> Anthony > > >> > > >> -- > > >> PHP Internals - PHP Runtime Development Mailing List > > >> To unsubscribe, visit: http://www.php.net/unsub.php > > >> > > >> > > > hi, > > > > > > do we want to change the default for this in PHP7? > > > > Honestly, I am not sure about this anymore. There is a significant > > performance benefit in doing client-side prepares. Last year I attempted > > to switch to server-side prepares on Etsy's production servers but it > > added 30-40ms of page latency because of the extra round trips. And yes, > > we were doing too many queries, but I fear if we change this default > > people won't understand where this slowdown is coming from. > > > > Of course, in some rare cases using server-side prepares might speed > > things up because of prepared statement caching in the server, but I > > have yet to see a case where that caching outweighs the extra tcp > > roundtrip overhead. > > > > I do agree that the default should probably be server-side since it is > > the least surprising. We just need to make it very very clear in the > > upgrade doc that this change will likely slow down peoples' apps and > > show them how to turn client-side prepares back on. > > > > -Rasmus > > > > I don't think we should remove the option, just change the defaults, and > most people would be fine switching back to the emulation, but it should be > their conscious decision imo. > Currently many people aren't aware that they are using client side > prepares, and they are pretty much ignore the fact, that they can be > exposed to sql injections (for example via using mismatching client and > server encodings or not properly quoting the identifiers: > http://www.codeyellow.nl/identifier-sqli.html because they think that > server side prepared statements would be immune to this kind of problems). > I think it would be better to change the default in a major version, if the > tradeoff is performance vs security, and if they think that they are okay > with the emulation, they can change it back. > > > ps: > don't forget that some/many of our users are still using php on a single > server setup, where the mysql connection is done through a unix socket > instead of the network stack, so the roundtrip there will be even less > noticable, and usually those are the kind of users, who need safe defaults > because they can't afford to be aware or change settings/code for their > apps. >
Hi, for me there is two usage of prepared statements : #1 : safely handle variables #2 : performance in batch traitments The first one want emulated prepared statments and the second need true prepared. It's possible to add a simplier method for the first one case, and let prepare() do a true prepare by default. For example here we extends PDO to add the q() shortcut. This shortcut basicaly do that : public function q($statement, array $params) { $stmt = $this->prepare($statement, [PDO::MYSQL_ATTR_DIRECT_QUERY => true]); return $stmt->execute($params); } -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php