Re: multiple CREATE FUNCTION AS items for PLs

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Hannu Krosing <hannu(at)krosing(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: multiple CREATE FUNCTION AS items for PLs
Date: 2012-12-28 15:23:20
Message-ID: 50DDB968.6010708@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 12/28/2012 03: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.
>

Quite true, but I have wanted something along the lines of function
attributes for a long time (can't find the email thread right now, but I
do seem to recall it being discussed in some form), so I think there's a
good case for the OPTIONS mechanism.

Making the language handler pull this out of the function text seems a
bit ugly too.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-12-28 15:25:38 Re: SPI API and exceptions
Previous Message Pavel Stehule 2012-12-28 15:09:19 Re: enhanced error fields