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