Re: Wishlist of PL/Perl Enhancements for PostgreSQL 8.5

From: Richard Huxton <dev(at)archonet(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Filip Rembiałkowski <plk(dot)zuber(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Wishlist of PL/Perl Enhancements for PostgreSQL 8.5
Date: 2009-10-06 19:45:26
Message-ID: 4ACB9E56.7090900@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alvaro Herrera wrote:
> Filip Rembiałkowski escribió:
>> 2009/10/6 Richard Huxton <dev(at)archonet(dot)com>
>>
>>> Are we looking down the wrong end of the telescope here? What if we had
>>> something more like the "C" binding for functions:
>>>
>>> CREATE FUNCTION foo(int,text,int) AS 'MyModule::internal_foo' LANGUAGE
>>> plperl;
>>> If you want inter-function calls you use internal_foo.
>>>
>> this really would be a great feature for many plperl users.
>> ( I'm not sure how it breaks current PL model in postgres)
>
> This would be a pain for dumps, because the user would have to install
> the modules separately. Maybe we could have a different language (say
> plperl2 for lack of a better name) that could work this way; if you
> really wanted to do this, you could.

I was assuming it would be smart enough to issue a "use MyModule" itself
(the same way the C library does). As far as pg_dump is concerned it
probably needs to be taught how to bundle external files - custom
tsearch dictionaries get left behind too.

It almost certainly would need to be call plperlmod or some such of
course - taking backwards compatibility away will just mean you have
loads of perl hackers chasing after you with sharpened onions.

--
Richard Huxton
Archonet Ltd

In response to

Browse pgsql-general by date

  From Date Subject
Next Message pere roca 2009-10-06 19:47:04 interface for "non-SQL people"
Previous Message Alvaro Herrera 2009-10-06 19:16:55 Re: attempted to lock invisible tuple - PG 8.4.1