From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Hannu Krosing <hannu(at)krosing(dot)net> |
Cc: | 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 08:15:08 |
Message-ID: | 1356682508.20017.8.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2012-12-28 08:24:30 | Re: multiple CREATE FUNCTION AS items for PLs |
Previous Message | Kyotaro HORIGUCHI | 2012-12-28 08:07:48 | Re: Performance Improvement by reducing WAL for Update Operation |