On 12/16/2012 07:20 PM, Hannu Krosing wrote:
> On 12/16/2012 07:03 PM, Tom Lane wrote:
>> Peter Eisentraut <peter_e@gmx.net> writes:
>>> When you do
>>> CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
>>> AS $$
>>> source code here
>>> $$;
>>> it internally creates a "source file" that contains
>>> ---
>>> def __plpython_procedure_foo_12345():
>>> source code here
>>> ---
>>> It would be useful to be able to do something like this instead:
>>> ---
>>> some code here
>>> def __plpython_procedure_foo_12345():
>>> some more code here
>>> ---
>>> This would especially be useful for placing imports into the first
>>> part.
>> Sure, but wouldn't it be cleaner to do that via some language-specific
>> syntax inside the function string? I'm imagining some syntax like
>>
>> CREATE FUNCTION ... AS $$
>> global[ some definitions here ]
>> function code here
>> $$;
>>
>> where the PL would be responsible for pulling off the "global" chunk
>> and structuring what it outputs accordingly.
> 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
On further thought the function name should just be what it is defined
in postgresql, like this
CREATE FUNCTION foo(a,b,c) AS $$ import x from __future__ import nex_cool_feature
def helper_function(x): ...
def foo(a,b,c): defined function body here
def bar(i,j): function body for bar(i,j)
$$ language plpythonu;
if the above definition saved the whole compiled unit as module
pg_functions.foo then
we could define postgresql/plpython function bar() by importing the same
module
CREATE FUNCTION bar(a,b,c) AS $$ form pg_functions.foo import bar
$$ language plpythonu;
This is not as simple as this, as we still need to find the source for
foo in case bar() gets
called first and module foo is not yet saved, but this could be one
approach to having
python modules without introducing extra syntax at postgreSQL level.
> but this would not be backwards compatible, at least not in any
> obvious way.
This is still unfortunately true :(
------------------------
Hannu
