Re: multiple CREATE FUNCTION AS items for PLs

On 12/28/2012 09:15 AM, Peter Eisentraut wrote:
> 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
You mean something along the lines of how source encoding is
defined in http://www.python.org/dev/peps/pep-0263/ ?

Sounds like a plan :)
> 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.
>
I would still not name the defined function with any special static name
(like the samples __pg_main__) but have it default to the name of
PostgreSQL-defined function with possibility to override :

I don't much like the name __pg_main__ for the exported function what
about __call__ ?

__call__ is used when making an object callable in python, but is not
used at module
level so modules can't be callables in python.

Maybe just export the function with the same name as is defined in
CREATE FUNCTION ?

And in case we do want to override it, call it

CREATE FUNCTION foo(a int,b int, c text) AS $$
# plpython: module modulename
import x,y,z

def foo(a,b,c):
return a + b + c

def foo2(a,b,c):
return foo(a,b,int(c))

__call__ = foo2

$$ language plpythonu

If we always require the export using __call__ in new-style pl/python
functions we could
leave out the "# plpython: module " part altogether and just test for
__call__ in the compiled
modules namespace after trying to compile the source code as module and
re-compile
using current methods if this fails.

To make this fast also for old-style functions, we should store compiled
bytecode (.pyc) in
database as well, perhaps putting it in pg_proc.probin as a base64
encoded string (probin
is not used fro non-C functions) or adding a new bytea column
pg_proc.procode especially for this.

the module name could default to something more predictable, like
function name + argtypes
so that it would become exportable by other plpython functions

thus

CREATE FUNCTION foo(a int,b int, c text)

would create module

plpy.modules.foo_int4_int4_text

and

CREATE FUNCTION foo()

would become simply

plpy.modules.foo

in this case we could reuse the code so that if foo(a,b,c) from the previous example needs to be exported it would be just

CREATE FUNCTION foo(a int,b int, c int) AS $$
from plpy.modules.foo_int4_int4_text import foo2
__call__ = foo2
$$ language plpythonu

or even simpler

CREATE FUNCTION foo(a int,b int, c int) AS $$
from plpy.modules.foo_int4_int4_text import foo2 as __call__
$$ language plpythonu

-------------------------------
Hannu

------------
Hannu