Re: php with postgres - Mailing list pgsql-hackers

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.boerger@post.rwth-aachen.de
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly
> 

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