On 12/16/2012 07:03 PM, Tom Lane wrote:
Peter Eisentraut <pete...@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





--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to