Re: Major upgrade to ext/pgsql

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