PostgreSQL Needs Improved pl/Perl
David Wheeler
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 <el...@varlena.com>
> Date: February 29, 2004 11:37:54 AM PST
> To: Andrew Dunstan <and...@dunslane.net>
> Cc: PostgreSQL-development <pgsql-...@postgresql.org>, David
> Wheeler <da...@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
> el...@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
Alex J. Avriette
Hi, David..
> 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,
My two favorite topics, perl and postgres. Cool.
> 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.
What do you see as needing to be done on the perl community side of
things?
> Anyone interested in helping out?
Sure, I'll do what I can...
> >Some requirements for pl languages are these:
> > * support query execution
As far as I know, this is done through DBD::SPI, which has been
broken for a while (or, rather, only works in postgres 6). Has
this changed? If not, we don't have query execution.
> > * support trigger functions
We don't have this?
> > * support for all built-in datatypes, e.g. easy
> > array support for pl languages which have
> > natural arrays, sets or dictionaries.
I'm not sure exactly how you would implement this. plperl takes,
of course, its arguments in @_. You'd have to do something like
make arrays arrayrefs or some object or other. In many cases, I'm
not sure this is worth the effort, as perl supports (presently)
returning cursors and (I believe) records.
> >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.
I do like the idea of extending plperl. For me personally, the
two biggest concerns are the inability to issue queries, and
the inability to return multiple-record results. A cursor just
doesn't cut it.
Alex
--
al...@posixnap.net
Alex J. Avriette, Unix Systems Gladiator
Sebastian Riedel
Alex J. Avriette wrote:
I agree with Alex.
Drop me a note if some more manpower is needed. ;)
>Alex
>
>--
>al...@posixnap.net
>Alex J. Avriette, Unix Systems Gladiator
>
>
>
Cheers,
Sebastian Riedel
Elein
> On Sun, Feb 29, 2004 at 11:50:00AM -0800, David Wheeler wrote:
>
> Hi, David..
>
> > 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,
>
> My two favorite topics, perl and postgres. Cool.
>
> > 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.
>
> What do you see as needing to be done on the perl community side of
> things?
>
> > Anyone interested in helping out?
>
> Sure, I'll do what I can...
>
> > >Some requirements for pl languages are these:
> > > * support query execution
>
> As far as I know, this is done through DBD::SPI, which has been
> broken for a while (or, rather, only works in postgres 6). Has
> this changed? If not, we don't have query execution.
>
> > > * support trigger functions
>
> We don't have this?
If there is no db access support, there certainly is no
trigger function support.
>
> > > * support for all built-in datatypes, e.g. easy
> > > array support for pl languages which have
> > > natural arrays, sets or dictionaries.
>
> I'm not sure exactly how you would implement this. plperl takes,
> of course, its arguments in @_. You'd have to do something like
> make arrays arrayrefs or some object or other. In many cases, I'm
> not sure this is worth the effort, as perl supports (presently)
> returning cursors and (I believe) records.
>
I'm not talking here about tuple to array conversion. I'm
talking about a column value which is an array. We've added some
very nice support for arrays recently however, they have not
been mapped to the nice perl array functionality. (This is
a hand waving statement--I would need to do some experimentation
to find out what should do what.)
> > >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.
>
> I do like the idea of extending plperl. For me personally, the
> two biggest concerns are the inability to issue queries, and
> the inability to return multiple-record results. A cursor just
> doesn't cut it.
Good point wrt returning sets of tuples. There is the sibling
issue of returning tuples from plperl routines. These are both
tied into the db accessibility.