Thread

Re: [HACKERS] PL/Lang (was: Priorities for 6.6)

Hannu Krosing <hannu@trust.ee> — 1999-06-09T19:28:19Z

Dmitry Samersoff wrote:
> 
> 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 function
>  executed
>  Add some string and regex manipulation functions.
>  Add exception handling.

What we really need is a better PL interface, the current one has 
quite a few limitations. Corba may help here, but _not_ a simple 
Corba wrapper of existing api

> All completely non standard thing may (and should) be done outside of postgres
> or in worst case by DYNALOAD mechanic.

Currently we are doing it in your "worst case" way :)

the v6.5 has even special scripts to create/destroy PLs. Only SQL and 
internal (compiled-in C) are "embedded" in non-removable way. 

Even PL/PGSQL must be installed to be used

> 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.

Compare this to Zope - using an advanced language to craft a special
tool
(in this case application server), which can both be used from other
servers 
but also has its own server (also written in python) which can
outperform 
apache in many usage patterns. And it has even a small SQL server
(gadfly)
embedded for both example of SQL adapter and for smaller scale work
(also 
written in python)
I think this achieves both the slickness of php3 and with extendability
of perl.

Now - what has it to do with embedding languages in PostgreSQL?

IMHO having better support for PLs should go further than just calling 
functions in SELECT or triggers - to make it possible for people to
easily 
add new types/indexing schemes the PL should also be usable for
input/output 
functions, access methods and maybe even for prototyping new fe/be
protocol.

I hope to get a draft implementation of this in 6.5 before its official
launch :)

-------------------
Hannu