Received: from mail.postgresql.org (webmail.postgresql.org [216.126.85.28]) by mail.postgresql.org (8.11.1/8.11.1) with SMTP id eBU2DDL60033 for ; Fri, 29 Dec 2000 21:13:13 -0500 (EST) (envelope-from pgsql-interfaces-owner@postgresql.org) Received: from snoopy.mohawksoft.com ([216.41.12.227]) by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id eBRDhUL15940; Wed, 27 Dec 2000 08:43:30 -0500 (EST) (envelope-from markw@mohawksoft.com) Received: from mohawksoft.com (IDENT:markw@snoopy.mohawksoft.com [216.41.12.227]) by snoopy.mohawksoft.com (8.11.0/8.11.0) with ESMTP id eBRDkFF18621; Wed, 27 Dec 2000 08:46:15 -0500 Message-ID: <3A49F2A7.77CEE0E1@mohawksoft.com> Date: Wed, 27 Dec 2000 08:46:15 -0500 From: mlw X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-Mohawk i686) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Momjian CC: PostgreSQL-development , PostgreSQL-interfaces Subject: Re: PHP and PostgreSQL References: <200012270556.AAA19258@candle.pha.pa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Archive-Number: 200012/254 X-Sequence-Number: 600 Bruce Momjian wrote: > > I have been asked by the major PHP developer Rasmus Lerdorf to see if > the PostgreSQL/PHP interface needs any improvements. > > Is the current PostgreSQL interface module in PHP adequate? Does it > support all the current libpq features? > > If not, would someone submit some patches to the PHP folks. They want > us to work well with PHP. They are basically encouraging us to improve > it in any way we can. In a current project, I am using Postgres, Oracle, and PHP. I think PHP's API is very complete and usable, I can't think of anything we've run into that was a result of PHP lacking a feature. The only thing I'd like to see would be an Oracle construct moved to Postgres. The idea that we can "prepare" a statement then execute it multiple times without going through the planner more than once. This would also require the ability to create and set arbitrary variables in a Postgres session. Since these are programmatic queries, only a handful of different SQL queries are ever executed. The ability to cache the planned query tree (is this the right terminology?) in a shared block, and simply reuse it, in the multiple back-ends, with a new variable value, would speed up some of the more complex queries, I guess. -- http://www.mohawksoft.com