On 12/17/2012 10:34 PM, Peter Eisentraut wrote:
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')
How about using a GUC for setting calling convention?
This SET can be even done as part of CREATE FUNCTION .
CREATE FUNCTION $$ ... $$ ... SET plpython.cc=9.2;
---------------------
Hannu
But this is also a lot more typing, so the two-part AS solution still
has some appeal if you just want an import.
Import is just a small sub-case of what you would want in your module
environment. And as it is really done only once per backend anyway -
starting the second time it is just a dictionary lookup - it should not be
singled out, at least not for performance reasons.
-----------------------------
Hannu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
