Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101049
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain koalephant.com designates 206.123.115.54 as permitted sender)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
In-Reply-To: <513ec8cf-6690-0bfa-bf20-b3a38620036b@beccati.com>
Date: Sat, 4 Nov 2017 23:24:58 +0700
Cc: Scott Arciszewski <scott@paragonie.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <361D4C9A-F17C-4572-B162-5EFF94D558D3@koalephant.com>
References: <CAKws9z1CeGHDmJ7hvX=mTXabMY+2fWgCjJw1N03bLZ=6PAsVng@mail.gmail.com> <7e7d69c9-8383-9cd0-9a54-0e7e4bb80775@beccati.com> <CAKws9z0zX8z2Lw4SL5yBOzx6h9Prd1+ZNNGHGz460JjsPSJd=g@mail.gmail.com> <513ec8cf-6690-0bfa-bf20-b3a38620036b@beccati.com>
To: Matteo Beccati <php@beccati.com>
Subject: Re: [PHP-DEV] Idea: PDO - Single-round-trip prepared statements
From: php-lists@koalephant.com (Stephen Reay)


> On 4 Nov 2017, at 14:28, Matteo Beccati <php@beccati.com> wrote:
>=20
> Hi,
>=20
>> On 03/11/2017 21:25, Scott Arciszewski wrote:
>> =E2=80=8BMySQL calls it an X Protocol, apparently.
>>=20
>> https://dev.mysql.com/doc/internals/en/x-protocol-use-cases-use-cases.htm=
l#x-protocol-use-cases-prepared-statements-with-single-round-trip
>=20
> OK, which is something that neither libmysqlclient nor mysqlnd seem to
> support.
>=20
>=20
>> We don't want to disable prepared statements (that constant's name is
>> somewhat scary).
>=20
> 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?
>=20
>=20
>> We don't want to emulate prepared statements (although we'll probably
>> have to respect the current configuration).
>=20
> At the very least we should turn it off as a default on MySQL.
>=20
>=20
>> 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:
>>=20
>> 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
>>=20
>> =E2=80=8B(In case it wasn't clear, I'm very much NOT a fan of emulated pr=
epares,
>> and in EasyDB we go out of our way to disable this feature.)
>=20
> I'm not opposed to a new method, but I think it would be confusing.
>=20
> Moreover with safeQuery you'd miss all the possibilities to bind
> parameters etc, offered by PDOStatement.
>=20
>=20
> Cheers
> --=20
> Matteo Beccati
>=20
> Development & Consulting - http://www.beccati.com/
>=20
> --=20
> 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 a=
s sql on the server.

So while most apps don't need to reuse the prepared statement they benefit f=
rom the more bulletproof parameterization, IMO.
See the recent Wordpress/Anthony bullshittery for why string manipulation "p=
repare" is a problem.

Also - why does this need a new method? Can't it be an option to PDO (eg lik=
e emulated prepared statements option) and similar to emulated prepares (whi=
ch 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.=