Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:88101 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36696 invoked from network); 7 Sep 2015 17:27:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Sep 2015 17:27:52 -0000 Authentication-Results: pb1.pair.com header.from=tyra3l@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=tyra3l@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.169 as permitted sender) X-PHP-List-Original-Sender: tyra3l@gmail.com X-Host-Fingerprint: 209.85.212.169 mail-wi0-f169.google.com Received: from [209.85.212.169] ([209.85.212.169:33714] helo=mail-wi0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DC/60-34134-719CDE55 for ; Mon, 07 Sep 2015 13:27:51 -0400 Received: by wiclk2 with SMTP id lk2so95289200wic.0 for ; Mon, 07 Sep 2015 10:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PgBkDqc7RCkhqVB9HQWMNqW7f/6Gyk2kEl8kR0ODXwU=; b=af+Hjpi274k0F1TSwxWMzV3LNKfFvyK+l4GAyAsqMgtNJx17nesA0m9SBXBnhHt9Ld OY3+gGRVZD/dLWL+zeQMXF9P/3JgCsLTQAkDo8SqynahcWa1uLSaMX416OY72Q6ZbJqa WIH9z5zEZ0lr7FZpkxZrn5WS2r7D247gdlZmP81NAQuMnQPGjmjNhmMklL+9LOiOG3xk NEbzxtdW/746OwghzohxuKQYCmrLIw/14+cJfPgawrWjZC4B5GXsXKFnCQRLqZwhyKYA bwfudYyGUB9UoijTIVevH9hfgDMOcG20RfEyInjtZIhgKCkvc263R1I5/wrK2Bor3Luy HjbA== MIME-Version: 1.0 X-Received: by 10.194.192.166 with SMTP id hh6mr36464338wjc.127.1441646867743; Mon, 07 Sep 2015 10:27:47 -0700 (PDT) Received: by 10.28.180.85 with HTTP; Mon, 7 Sep 2015 10:27:47 -0700 (PDT) In-Reply-To: <1441581781.24572.8.camel@kuechenschabe> References: <7A.E4.59944.DF67CE55@pb1.pair.com> <1441581781.24572.8.camel@kuechenschabe> Date: Mon, 7 Sep 2015 19:27:47 +0200 Message-ID: To: =?UTF-8?Q?Johannes_Schl=C3=BCter?= Cc: Andrea Faulds , PHP Internals Content-Type: multipart/alternative; boundary=047d7bb709507189ea051f2b91fc Subject: Re: [PHP-DEV] Re: PDO: Disable emulated prepares by default? From: tyra3l@gmail.com (Ferenc Kovacs) --047d7bb709507189ea051f2b91fc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 7, 2015 at 1:23 AM, Johannes Schl=C3=BCter wrote: > On Sun, 2015-09-06 at 18:25 +0100, Andrea Faulds wrote: > > Hi Scott, > > > > Scott Arciszewski wrote: > > > Inspired by http://stackoverflow.com/a/12202218/2224584 > > > > > > Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared > > > statements off by default, and still allow developers to turn it on i= f > > > they really want them? > > > > > > For now my code works around this design decision, but not everybody > > > is cognizant of this behavior. > > > > I don't know if there's really still time to add this in PHP 7.0, but I > > think emulated prepares being switched off would be a good idea. One > > Good enough to take the performance hit by the extra roundtrip? > > > reason in particular is that this means we'd get properly typed results= , > > rather than just strings, which would work better with PHP 7's new > > scalar type hints. PDO returning strings everywhere when using emulatio= n > > was one thing I was completely unaware of until I turned on strict > typing. > > For some definition of "properly". Large integers might still become > strings, same for decimals etc. Also if you might use other databases > than MySQL still anything might happen. > > Also mind that there are subtle differences on what can be done. A bit > constructed example but in MySQL you can't prepare > CREATE TABLE foo (id INT DEFAULT ?) > while PDO would let you do this. > > johannes > > also, binding ASC/DESC for ORDER BY is a common gotcha when moving from emulated prepares to native. --=20 Ferenc Kov=C3=A1cs @Tyr43l - http://tyrael.hu --047d7bb709507189ea051f2b91fc--