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  (marcus.boerger@t-online.de (Marcus Börger))
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:

Previous
From: "Jenny -"
Date:
Subject: locking mechanism
Next
From: ivan
Date:
Subject: did you read my mails ?