Re: php with postgres - Mailing list pgsql-hackers
From | ivan |
---|---|
Subject | Re: php with postgres |
Date | |
Msg-id | Pine.LNX.4.56.0307132201420.24176@rex.anfa.pl Whole thread Raw |
In response to | Re: php with postgres (Joe Conway <mail@joeconway.com>) |
Responses |
Re: php with postgres
|
List | pgsql-hackers |
what aoubt stream ? in plpgsql you can just write command INSERT ... or DELETE if you want sht like this in php you need to correct zend i think . in php all var is declared as variant type but we need look at realy type. I have other view, to first write php interpreter to postgres, and then write a translator, which translate plphp code to C code . I cound be only a another way, to remember about speed (compiled code is always faster then src ) . Php source will be to testing, and to relese will be option to translate this src to C src and then compile it. ps. there could be also interpreter with debug version and relese version (without checking some things) dont forget about default value of functions args !! :> On Sun, 13 Jul 2003, Joe Conway wrote: > Jan Wieck wrote: > > I had been briefly talking with Marcus Boerger (included in CC) from the > > PHP team about it. He knows the PHP5 SAPI embed well. Can you include > > him into the team (if not already)? > > Sure! > > > From what I know about this SAPI I think the PL/Tcl implementation > > would be a good point to start from, as it looks very similar with > > respect to the possibilities. > > I was going to start from PL/R, which is a descendent of PL/Tcl -- > reason being, in PL/R I've already got SRF/table-function support and > polymorphic argument/return-type support working. Also, I've done a fair > amount of work to preserve arrays and composite types as they move > back-and-forth. > > My plan is to add a few missing things to PL/R over the next couple (or > so) weeks, and then start PL/PHP from that: > 1) Cache lookup based on function oid and argument signature ala the > patch I recently sent in (and improved by Tom) for PL/pgSQL -- this > is needed to properly support polymorphic arguments. > 2) Trigger support -- just haven't needed this so far, but we'll want it > in PL/PHP, so I may as well add it to PL/R too. > 3) Re-add nested error handling -- I removed this from PL/R early on > just to simplify life. Should be easy to drop back in. > > I've read some examples posted regarding the PHP embed SAPI, and it > looks very similar to the R interpreter also. It should be fairly easy > to drop the PHP embed calls in for the libR calls. The bulk of the work > will be in modifying the data conversion functions that map Postgres > composite types and arrays to similar structures in PHP. > > Help on the PHP side of things would be most appreciated, because that's > the part I'm least familiar with. > > Joe >
pgsql-hackers by date: