Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15465
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Organization: Emini ApS
To: internals@lists.php.net
Date: Wed, 16 Mar 2005 11:48:18 +0100
User-Agent: KMail/1.6.2
Cc: Christopher Kings-Lynne <chriskl@familyhealth.com.au>,
	helly@php.net
References: <4237C24C.7000607@familyhealth.com.au>
In-Reply-To: <4237C24C.7000607@familyhealth.com.au>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <200503161148.18284.edink@emini.dk>
Subject: Re: [PHP-DEV] Major upgrade to ext/pgsql
From: edink@emini.dk (Edin Kadribasic)

I wouldn't call pgsql support in PHP stone age :)
I do think that this would be a very nice addition to php 5.1.

A few questions:

Why do we need pg_query_params. Isn't prepare/execute enough? 
pg_execute($conn, $stmt, $params) seem to be already taking care of the 
parameters passed. (btw. I wouldn't make $conn optional, it makes adding 
additional parameters later on pain).

How does this work over persistent connections? AFAIK trying to prepare a 
statment with the same name on the same connection will result in an error.

Edin


On Wednesday 16 March 2005 06:21, Christopher Kings-Lynne wrote:
> Hi,
>
> Attached is a patch that brings PostgreSQL support in PHP out of the
> stone age!
> It adds a five new functions:
>
> * pg_query_params
>
> Allows paramaterised queries (ie. no escaping required).  This really is
> just a libpq shortcut for prepare/execute
>
> libpq function: PQexecParams
>
> * pg_prepare
>
> Creates a named prepared query
>
> libpq function: PQprepare
>
> * pg_execute
>
> Executes a named prepared query
>
> libpq function: PQexecPrepared
>
> * pg_transaction_status
>
> Returns transaction status of a connection
>
> libpq function: PQtransactionStatus
>
> * pg_result_error_field
>
> Allows getting advanced diagnostics on errors, most importantly allows
> getting the SQLSTATE error code on errors, therefore finally pgsql users
> can identify errors by ID.
>
> libpq function: PQresultErrorField
>
> Notes
> -----
>
> I haven't attached docs or regression tests, these will follow if the
> patch is accepted (or before if you require)
>
> Should pg_query_params instead be folded into pg_query, with an optional
> 3rd parameter which would be the parameter array?  Would this then be
> difficult for clients to detect if the 3rd parameter is available to them?
>
> I've tested it all and seems to work fine, please review :)
>
> Cheers,
>
> Chris