PostgreSQL Needs Improved pl/Perl

P5P'ers,

I'm  forwarding this message on behalf of the PostgreSQL community. 
There's a fair bit of interest there in improving pl/Perl -- that is, 
the ability to write native database functions in Perl. I don't know 
what kind of time and resources the PostgreSQL developers have, but I 
think, like Elein, that there might be a good opportunity for 
collaboration here.

Anyone interested in helping out?

Regards,

David

Begin forwarded message:

> From: elein <elein@varlena.com>
> Date: February 29, 2004 11:37:54 AM PST
> To: Andrew Dunstan <andrew@dunslane.net>
> Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, David 
> Wheeler <david@wheeler.net>
> Subject: Re: [HACKERS] Server Side PL support
>
> This is a very interesting topic.  Joe Conway
> has a very good idea of pl requirements since
> he just implemented pl/R.
>
> Some requirements for pl languages are these:
>    * support query execution
>    * support trigger functions
>    * allocating storage for per statement function calls
>      This is like the SD[] dictionary in plpythonu.
>    * support for all built-in datatypes, e.g. easy
>      array support for pl languages which have
>      natural arrays, sets or dictionaries.
>    * enable easy fastpath functionality
>      or similar pl to pl function calls
>
> Note that array support, trigger and query support
> for plperl does not yet exist.
>
> IMHO extended support for plperl should have a relatively
> high priority.  We are actively reaching out to the
> perl community and full support of the interface is
> important.  Collaboration on the implementation is
> also possible--it has been discussed with some perl folks.
>
> elein
> elein@varlena.com
>
>
> On Sun, Feb 29, 2004 at 02:20:19PM -0500, Andrew Dunstan wrote:
>>
>> I have been taking a brief look at pltcl, and particularly its ability
>> to preload modules. By comparison with most of the core product this
>> seems to be somewhat out of date and unpolished (e.g. hardcoded path 
>> to
>> libpgtcl.so, no use of schemas for the supporting tables, lack of
>> comments). Since my understanding of tcl is extremely rusty, I didn't
>> dig further than that. However, I am interested in getting a similar
>> facility working for plperl, and thus wanted to start a discussion on
>> what general facilities could/should be made available to server side
>> PLs. Or should we just assume that each PL will create it's own 
>> support
>> tables?
>>
>> cheers
>>
>> andrew
>>
>>
>> ---------------------------(end of 
>> broadcast)---------------------------
>> TIP 7: don't forget to increase your free space map settings

• PostgreSQL Needs Improved pl/Perl by David Wheeler
• Re: PostgreSQL Needs Improved pl/Perl by Alex J. Avriette
• Re: PostgreSQL Needs Improved pl/Perl by elein
• Re: PostgreSQL Needs Improved pl/Perl by Sebastian Riedel