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
but this would not be backwards compatible, at least not in any obvious way.
-------------------
Hanniu
>> CREATE FUNCTION already supports multiple AS items. Currently, multiple
>> AS items are rejected for all languages but C. I'd imagine lifting that
>> restriction and leaving it up to the validator to check it. Then any
>> language can accept two AS items if it wants and paste them together in
>> whichever way it needs. (The probin/prosrc naming will then become more
>> obsolete, but it's perhaps not worth changing anything about that.)
> I think doing it this way is a bad idea, mainly because (1) it won't
> scale to more than two items (at least not without great rearrangement
> of pg_proc) and (2) having two otherwise-unlabeled AS items isn't at all
> understandable or readable. For instance, which of the two is the
> global part, and why? The fact that C functions do it like that is a
> legacy syntax we're stuck with, not a good model to copy for other
> languages.
>
> regards, tom lane
>
>
