On 16/10/14 18:59, christopher jones wrote: > > The MySQL team has been improving their server-side prepare code: > http://mysqlserverteam.com/re-factoring-some-internals-of-prepared-statements-in-5-7/
It may be worth clarifying some terms here since people are talking about restrictions that MySQL creates for itself and which are not normal limitations in other engines. This article identifies the simple fact that MySQL is still playing catchup when it comes to PARAMETRIZED statements. Something which is the norm in other engines. One of the best ways of maintaining security against SQLi IS to pass data as parameters and so anybody trying to be clever by replacing a text value by SQL fails at the first hurdle. Once using parameters then prepare is a required step anyway. It is not optional. It's facets like this which are one of the reasons that PDO is NOT a good base to build on top of as it assumes the lowest common denominator is the norm? Which it has to. Ulf stated early on in this thread re MySQL > - statement and parameter are send to the server independently > - the server builds the final statement string Is this ACTUALLY how it works? Since other engines prepare the statement and bind buckets to put the parameters in. They never 'build the final statement string' and there is no 'client side prepare' because the concept can't exist. Some other engines may support named parameters via client side juggling, but that just hides the underlying fixed order requirements it does not replace the bind process. PDO has a number of restrictions which prevent facilities available on other engines from being used. Is this just another area where the attempts to make every one seem the same is actually more of a hindrance than a help? Passing a fully assembled SQL statement over the wire should always be a last resort rather than the norm once it's content is provided via external routes. I don't need to call 'prepare' in Firebird, it will be handled as required so having that step carried out by the client side is the waste of traffic. The next version of Firebird will actually start caching prepared statements on persistent connections which I'm just waiting to play with! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
