Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72992
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain beccati.com designates 176.9.114.167 as permitted sender)
Message-ID: <5319EB3A.2060404@beccati.com>
Date: Fri, 07 Mar 2014 16:52:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: PDO_PGSQL improvements for 5.6
From: php@beccati.com (Matteo Beccati)

Hi,

I know I'm very late, but I really haven't had a chance until now. I do
have a few improvements for PDO_PGSQL that I'd really love to get into
PHP 5.6 if possible. They are about:

1. Cleaning up the #ifdef mess by raising the libpq requirements to
versions providing PQprepare, PQescapeStringConn, PQescapeByteaConn,
that is some 8.1.x / 8.2.x (which are way past EOL anyway).

2. Deprecate PDO::PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT which is
effectively equivalent to PDO::ATTR_EMULATE_PREPARES. There's no need to
keep and maintain both of them.

3. PQexecParams support. By default server side prepared statements are
used, which is a waste of time/resources in case the query has to be
executed just once. You can normally avoid that by using
PDO::ATTR_EMULATE_PREPARES, which is much faster, but forces PDO to
inline parameters in the queries. A newly introduced
PDO::PGSQL_ATTR_DISABLE_PREPARES will switch to use PQexecParams by
sending the query with placeholders and parameters separately, like
PQprepare does, without having to worry with the potential security
risks of ATTR_EMULATE_PREPARES.

Thoughts?


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/