Yes. I am looking at a few of these things (preloading, intra-perl
calling, array and tuple return), and I understand that CommandPrompt is
doing some plperl work too. They already have a plperl which does
triggers. My question was not "what functionality do we need from PLs?"
but rather "what do PLs need from the core for good support?" I
particularly had catalog support in mind, but there could be other areas
too.
I'm glad to see you support the efforts to make plperl something more
useful. One idea I had for a GForge/GBorg project when that gets going
is a place for collaborating on experimental plperl work, before it gets
merged back to the core.
cheers
andrew
elein wrote:
>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
>>
>>
>
>
>
