Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15469
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <4238E6A3.4090009@familyhealth.com.au>
Date: Thu, 17 Mar 2005 10:08:35 +0800
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Edin Kadribasic <edink@emini.dk>
Cc: internals@lists.php.net, helly@php.net
References: <4237C24C.7000607@familyhealth.com.au> <200503161148.18284.edink@emini.dk>
In-Reply-To: <200503161148.18284.edink@emini.dk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Major upgrade to ext/pgsql
From: chriskl@familyhealth.com.au (Christopher Kings-Lynne)

> I wouldn't call pgsql support in PHP stone age :)

Hmmm, you're obviously not a PostgreSQL developer, and been wondering 
why 2 year old postgresql technology hasn't been supported yet :D

> 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? 

It's a 1-1 mapping of the libpq PostgreSQL API.  Basically it allows you 
to avoid sql injection attacks and quoting, and also not have to worry 
about having to prepare/execute a named prepared query that, as you 
mention below, might collide with a previous one.  I chose to emulate 
the wisdom of the libpq API designers on this one.

Check here:
http://www.postgresql.org/docs/current/static/libpq-exec.html

> 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).

I made it optional simply to match the other postgresql functions, 
specifically pg_query.  It's easy enough to change if you like.

> 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.

Correct, but that's exactly the same as executing a PREPARE command via 
SQL instead of via the v3 protocol.  (Which people have been doing for 
years.)

PostgreSQL currently lacks adequate commands for properly resetting 
persistent connections :(  For instance, prepared queries and named open 
cursors will persist across persistent connections in PHP - but that's 
not new.

Chris