Re: php with postgres

Glad you got in touch with the right guys. Joe and Jan have both talked
about doing PlPHP for a while.

Marcus, would you check if PHP is using RESET ALL when passing
persistent connection to new clients? We added that capability a few
releases ago, specifically for PHP persistent connections, but I don't
think that ever got into the PHP code.

---------------------------------------------------------------------------

Marcus B?rger wrote:
> Hello ivan,
>
> Sunday, July 13, 2003, 10:12:43 PM, you wrote:
>
>
> i> what aoubt stream ?
> i> in plpgsql you can just write command INSERT ... or DELETE
> i> if you want sht like this in php you need to correct zend i think .
> i> in php all var is declared as variant type but we need look at realy type.
>
> In php we only have a few base types (int, float, bool, string) and some more
> complex types like array and objects. The general idea is that at least the
> base types can be converted without notice. This might be a problem when
> integrating php into postgres but i guess everything can be solved the php
> way. Since i also have zend commit rights i could fix things in this manner as
> long as the language itself doesn't change in any way.
>
> i> I have other view, to first write php interpreter to postgres, and then
> i> write a translator, which translate plphp code to C code . I cound be only
> i> a another way, to remember about speed (compiled code is always faster
> i> then src ) . Php source will be to testing, and to relese will be option
> i> to translate this src to C src and then compile it.
>
> The general idea should be to leave php as is. That is, it is an interpreter.
> During LT we were again able to speed it up very much. So performance
> difference from interpreter to a real php to c compiler shouldn't be a problem
> for the moment.
> Also i thing when someone consideres using php inside his database he a) does
> it because he doesn't know any other language or b) he uses very advanced
> language features. In both cases the performance problem is no issue.
> Additionally there are already tokenizers out which remove the
> compile step. So atm we only can't get rid of the interpreter overhead.
>
> Best regards,
> Marcus mailto:marcus(dot)boerger(at)post(dot)rwth-aachen(dot)de
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073