On 3 November 2014 09:18:08 GMT, Matteo Beccati <p...@beccati.com> wrote: >Hi all > >Resuming this once again after Anthony's blog post... > >On 16/10/2014 18:10, Ferenc Kovacs wrote: >> On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf <ras...@lerdorf.com> >wrote: >>> 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. > >Yes. For the record, pdo_pgsql and pdo_mysql seem to be the only PDO >drivers that can effectively emulate prepares. As far as I could tell, >the others ignore the attribute. For pgsql the default is to use >server-side prepares, so I'd be all for making both work consistently >by >default. > >However, I think PDO is fundamentally flawed in enforcing the use of >prepared statements even when 99% of the times the queries issued by a >PHP script need only to be executed once. It surely is a waste of >resources having to allocate a prepared query, execute it and >deallocate >it each and every time. I certainly wish there was something in the >mysql client/protocol similar to PQexecParams, which would be the best >of both worlds.
I think rhis Twitter exchange is very relevant here: https://twitter.com/dracony_gimp/status/528240781996605440?s=09 When using a one-shot call to query() with multiple statements (e.g. create temp table; populate temp table; select results) it's actually necessary with Postgres to switch on emulation, and for that emulation to allow multiple queries even though the DBMS wouldn't. We discovered this in moving from ext/postgres, where pg_query() doesn't attempt to prepare the query, so allows strings containing multiple statements. We therefore needed a compatible mode in order to switch to PDO. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
