On 09-Jun-99 Philip Warner wrote:
> At 14:40 8/06/99 +0400, you wrote:
>>Hello!
>>
>>On Tue, 8 Jun 1999, Jan Wieck wrote:
>>> This time, the Perl interpreter has to become a silly little
>>> working slave. Beeing quiet until it's called and quiet
>>> again after having served one function call until the big
>>> master PostgreSQL calls him again.
>>>
>>> This flexibility requires a real good design of the
>>> interpreters internals. And that's what I'm addressing here.
>>
>> I know exactly 1 (one) program that incorporate (embed) Perl interpreter
>>- it is editor VIM (well-known vi-clone from www.vim.org). I think anyone
>
> Apache also has Perl very nicely embedded (as opposed to available through
> indirect CGI calls); when it is embedded it automatically reloads and
> recompiles changed scripts.
IMHO, It's bad practice to embed Perl, C++ and so on into postgres.
because it slow down postgres, increase memory requirement
and amount of leaks and errors.
Postgres should use it's own language like plpgsql, and
it's better to point your mind to improve and speed up it.
For example:Add pre-compilation and syntax check while create functionexecutedAdd some string and regex manipulation
functions.Addexception handling.
All completely non standard thing may (and should) be done outside of postgres
or in worst case by DYNALOAD mechanic.
You can look at Apache's mod_perl and mod_php3 to compare two ways
mentioned above:
First - embedding perl with all it's history and lots of function completely
unnecessary and inconvenient for web programming.
Second - php3 - language initially developed to embed into apache.
---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...