Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101046
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain beccati.com designates 176.9.123.236 as permitted sender)
To: Scott Arciszewski <scott@paragonie.com>
Cc: PHP Internals <internals@lists.php.net>
References: <CAKws9z1CeGHDmJ7hvX=mTXabMY+2fWgCjJw1N03bLZ=6PAsVng@mail.gmail.com>
 <7e7d69c9-8383-9cd0-9a54-0e7e4bb80775@beccati.com>
 <CAKws9z0zX8z2Lw4SL5yBOzx6h9Prd1+ZNNGHGz460JjsPSJd=g@mail.gmail.com>
Message-ID: <513ec8cf-6690-0bfa-bf20-b3a38620036b@beccati.com>
Date: Sat, 4 Nov 2017 08:28:25 +0100
MIME-Version: 1.0
In-Reply-To: <CAKws9z0zX8z2Lw4SL5yBOzx6h9Prd1+ZNNGHGz460JjsPSJd=g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Idea: PDO - Single-round-trip prepared statements
From: php@beccati.com (Matteo Beccati)

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/