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.
> 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
