Re: multiple CREATE FUNCTION AS items for PLs - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: multiple CREATE FUNCTION AS items for PLs
Date
Msg-id 50DDE51C.1090408@2ndQuadrant.com
Whole thread Raw
In response to Re: multiple CREATE FUNCTION AS items for PLs  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On 12/28/2012 09:15 AM, Peter Eisentraut wrote:
> On Mon, 2012-12-17 at 16:34 -0500, Peter Eisentraut wrote:
>> Yes, this would be a good solution for some applications, but the only
>> way I can think of to manage the compatibility issue is to invent some
>> function attribute system like
>>
>> CREATE FUNCTION ... OPTIONS (call_convention 'xyz')
> An alternative that has some amount of precedent in the Python world
> would be to use comment pragmas, like this:
>
>          CREATE FUNCTION foo(a,b,c) AS $$
>          # plpython: module
>          import x
>           from __future__ import nex_cool_feature
>
>           def helper_function(x):
>              ...
>
>           def __pg_main__(a,b,c):
>               defined function body here
>
>          $$;
>
> The source code parser would look for this string on, say, the first two
> lines, and then decide which way to process the source text.
>
> This way we could get this done fairly easily without any new
> infrastructure outside the language handler.
Peter, are you expecting to make write this patch ?

If so, then the very same approach (except the comment pragma
magic which is not needed there) is already done in python-postgres/be plpy
language handler. ( git://github.com/python-postgres/be.git )
Except there the modules exported function is named __main__ :)

And as a matter of bikeshedding I'd still prefer to name exported
function __call__ .

-----------------
Hannu





pgsql-hackers by date:

Previous
From: Alastair Turner
Date:
Subject: Re: A stab at implementing better password hashing, with mixed results
Next
From: Pavel Stehule
Date:
Subject: Re: enhanced error fields