Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78130
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <5440E696.8050900@lsces.co.uk>
Date: Fri, 17 Oct 2014 10:51:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: "internals@lists.php.net >> PHP internals" <internals@lists.php.net>
References: <CAAyV7nFciZcsL+AW9W4GbhM+PhM3RhWOJ7G0iBQsEHfSWO2QmA@mail.gmail.com> <CAH-PCH6jVcXNtyySeY4EJZt2sQqhXFV=acO_x3HJb2f7WKtMPQ@mail.gmail.com> <543FE883.2070401@lerdorf.com> <54400765.90802@oracle.com>
In-Reply-To: <54400765.90802@oracle.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default
 for PDO_Mysql
From: lester@lsces.co.uk (Lester Caine)

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