On 12/16/2012 08:44 PM, Andrew Dunstan wrote:
On 12/16/2012 01:37 AM, Peter Eisentraut wrote:
So in practice this might look like this:
CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
import x
import y
$$,
$$
real code here
$$;
Bleah.
It seems obscure to say the least.
Why not have something along the lines of plperl's on_init setting to
load libraries? Among other things that would give you the advantage
of being able to preload them, and also of some consistency among PLs.
While plpython.on_init is a much needed feature, it is orthogonal to
what is discussed here.
AIUI Peters proposal aimed adding per-function preparation /
initialisation not something
to be run for initialising the whole interpreter.
Also - to make the plpython.on_init really useful - there should be some
way to have python
_modules_ inside postgresql
If we would redefine plpython functions to define their own _visible_
modules (currently
each has its own module but there is no way to reference it from others)
and have the
function stored in this module we could not only solve the problem of
plpython modules
but also for calling other plpython modules directly from python .
for example, if doing
CREATE FUNCTION foo(i int) RETURNS int LANGUAGE plpythonu $$
def foo(i):
return i+1
$$;
would also make this function available as plpy.modules.foo_int.foo
(meaning its global
namespace would be saved as plpy.modules.foo_int
then other plpy functions could call it directly by doing
from plpy.modules.foo_int import foo
I try to come up with a more detailed proposal along these lines.
----------------------
Hannu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
