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-17 21:34:22 |
Message-ID: | 50CF8FDE.9060805@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/16/12 1:20 PM, Hannu Krosing wrote:
> I was going to suggest some special function name to be pulled out of code
> passed to CREATE FUNCTION in line with
>
> CREATE FUNCTION foo(a,b,c) AS $$
> import x
> from __future__ import nex_cool_feature
>
> def helper_function(x):
> ...
>
> def __pg_main__(a,b,c):
> defined function body here
>
> $$;
>
> so that the whole text gets compiled into module at first call and the
> __pg_main__ will
> be the function that gets called as foo(a,b,c) from postgresql
>
> but this would not be backwards compatible, at least not in any obvious way.
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')
But this is also a lot more typing, so the two-part AS solution still
has some appeal if you just want an import.
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2012-12-17 21:42:54 | Re: Enabling Checksums |
Previous Message | Jeff Janes | 2012-12-17 21:30:29 | Re: Serious problem: media recovery fails after system or PostgreSQL crash |