Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113304 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 51072 invoked from network); 27 Feb 2021 16:02:07 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 27 Feb 2021 16:02:07 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A53711804D0 for ; Sat, 27 Feb 2021 07:51:38 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_20,KHOP_HELO_FCRDNS, SPF_HELO_NONE,SPF_NONE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from processus.org (ns366368.ip-94-23-14.eu [94.23.14.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 27 Feb 2021 07:51:37 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by processus.org (Postfix) with ESMTPA id 778DD5101324; Sat, 27 Feb 2021 15:51:36 +0000 (UTC) To: Rowan Tommins , internals@lists.php.net References: <499c2591-fb11-1b9d-d402-39f7ec1c6b85@themad.com.au> <6EC89E9A-035D-4D2B-97D7-845DC4FF3E32@koalephant.com> <347e565f-f90a-5fc6-efcf-e28856ad00dc@gmail.com> Message-ID: <23cf71d2-4fed-ceab-6c63-c826af01bb36@processus.org> Date: Sat, 27 Feb 2021 16:51:35 +0100 MIME-Version: 1.0 In-Reply-To: <347e565f-f90a-5fc6-efcf-e28856ad00dc@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Authentication-Results: processus.org; auth=pass smtp.auth=pierre-php@processus.org smtp.mailfrom=pierre-php@processus.org X-Spamd-Bar: / Subject: Re: [PHP-DEV] PDO integer changes in 8.1 will stop many websites I support From: pierre-php@processus.org (Pierre) Le 27/02/2021 à 15:39, Rowan Tommins a écrit : > On 27/02/2021 14:03, Pierre wrote: >> I'm curious, why are you stating that emulated prepares are not >> useful anymore ? > Emulated prepares are a slightly dangerous idea, because they give the > impression of separating query from data, but actually use string > escaping internally. Historically, I believe there were previously > scenarios where real prepared queries were not available, which no > longer apply. Yes I was aware of this, I do more explicit prepares when I really need those, it doesn't happen quite often. I still do from time to time but using the ext-pgsql extension. I don't use MySQL anymore since I succeeded in freeing myself from Drupal :) Drupal uses emulate prepare because it allows it set value placeholders in queries, which is very convenient for their query builder. >> Using the prepare() function as I remember correctly seems to be the >> only way to execute a query that allows you to pass an array of >> parameters instead of having to call PDOStatement::bindParam() for >> each parameter. > Regardless of whether you use emulated or real prepares, the > PDOStatement's execute method can be called with an array of > parameters, and as far as I know always could. Yes, but PDOStatement::execute() explicitly documents that it can be used only for prepared queries. If that's true that means there is no alternative for binding value params in a query than using it. I didn't remember (long time I didn't use PDO when I wrote my first email) only prepare() allows you to write value placeholders in queries. ext-pgsql has the pg_query_params() for doing this, which is very convenient, PDO can only do this using emulate prepare. >> That's the only reason I use emulated prepares anyway, it allows to >> use this API without actually preparing the queries, which is what I >> want most of the time. > > This is a slightly different point: when running a query once, it > seems to currently require two database round trips: one to prepare, > and one to execute. I don't know what the underlying drivers support > here, but it would be useful to have a method on the PDO object itself > that let you provide a parameterised string and its data in one go. > That would be safer than using emulated prepares, and (hopefully) more > efficient than using real prepares. > > Regards, I'm not sure it requires two round trips when you use prepare() along with emulated prepare, at least I never noticed it (and I did profile by observing SQL side logs more than once, for example one thing that do a lot of roundtrips is the getColumnMeta() call). 2 roundtrips are required if you really prepare the query. Anyway, thank you very much for answering. It's sad PDO doesn't have a pg_query_params() equivalent method, most people would stop using prepare() if that was the case. Regards, -- Pierre