> On 4 Nov 2017, at 14:28, Matteo Beccati <p...@beccati.com> wrote: > > Hi, > >> On 03/11/2017 21:25, Scott Arciszewski wrote: >> MySQL calls it an X Protocol, apparently. >> >> https://dev.mysql.com/doc/internals/en/x-protocol-use-cases-use-cases.html#x-protocol-use-cases-prepared-statements-with-single-round-trip > > OK, which is something that neither libmysqlclient nor mysqlnd seem to > support. > > >> We don't want to disable prepared statements (that constant's name is >> somewhat scary). > > Well, in my experience there are very few occasions that actually > benefit from prepared queries. I know it can sound scary, but I do > believe that more than 95% of the times prepared queries are just > wasting resources. The few patterns that actually benefit from them > could just enable them temporarily. Not ideal, but we are kinda used to > it with PDO, aren't we? > > >> We don't want to emulate prepared statements (although we'll probably >> have to respect the current configuration). > > At the very least we should turn it off as a default on MySQL. > > >> We just need a separate method (my proposed safeQuery() being distinct >> from prepare()) that uses whatever that driver's single-round-trip >> prepare-and-execute equivalent API is. If none is available for the >> given driver, we need to decide whether to: >> >> 1. Throw a PDOException, or >> 2. Silently use two round trips in the background so it "just works" >> even if it's a slight performance hit >> >> (In case it wasn't clear, I'm very much NOT a fan of emulated prepares, >> and in EasyDB we go out of our way to disable this feature.) > > I'm not opposed to a new method, but I think it would be confusing. > > Moreover with safeQuery you'd miss all the possibilities to bind > parameters etc, offered by PDOStatement. > > > Cheers > -- > Matteo Beccati > > Development & Consulting - http://www.beccati.com/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
(Sending again from on-list address) With MySQL "true" prepared queries mean the data segments are never parsed as sql on the server. So while most apps don't need to reuse the prepared statement they benefit from the more bulletproof parameterization, IMO. See the recent Wordpress/Anthony bullshittery for why string manipulation "prepare" is a problem. Also - why does this need a new method? Can't it be an option to PDO (eg like emulated prepared statements option) and similar to emulated prepares (which wouldn't need to connect in the prepare() stage) it just stores the query until you call exec($data) and then makes one call to the DB server. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
