Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73480
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sensational.ch designates 195.226.6.199 as permitted sender)
MIME-Version: 1.0
Date: Sun, 30 Mar 2014 13:41:17 +0200
Message-ID: <CAGKNXQEozpALEFN6arc17unNa-4FiScRNth4yOWDk75EBso1eA@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: pdo_pgsql-Improvements
From: phofstetter@sensational.ch (Philip Hofstetter)

Hello,

over the last few days I have been playing with pdo_pgsql a bit in
order to make some wishes I've always had finally come true.

So far, I've added

1) support for automatically parsing JSON result column (if the json
extension is enabled)
2) support for automatically parsing array columns
3) support for turning timestamp and date columns into DateTime objects
4) a pgsqlQuoteIdentifier method to correctly quote table and column
names (arguably, this should maybe go into PDO base)

The first three features need enabling by setting
PDO::PGSQL_ATTR_ADVANCED_TYPE_CONVERSIONS to true on either the PDO
object or as a driver specific parameter to prepare().

Parsing the arrays feels especially important to me as the various
userland solutions out here are either quite slow, unreadable or
outright buggy. Arrays are a core feature of Postgres and map really
well to arrays in PHP.

1 and 4 also have unit tests. Tests for 2 and 3 will be coming too.

I'm writing here in order to find out whether you think that improving
the pdo_pgsql driver is something you would think makes sense for you,
in which case I will write an official RFC.

My work so far is on

https://github.com/pilif/php-src/commits/pdo_pgsql-improvements

Stuff I still would also want to add is

1) support for DateTimeInterface bound parameters
2) support for Array as bound parameters (maybe - not sure if doable)
3) support for the new features of PGResult (9.3 and later) that
expose information of what columns have failed a unique key
constraint, for example.
4) Unit tests for everything, of course

So, asking again: Do you guys think, this is worth writing an RFC for?

Thank you in advance

Philip