multiple CREATE FUNCTION AS items for PLs - Mailing list pgsql-hackers

From Peter Eisentraut
Subject multiple CREATE FUNCTION AS items for PLs
Date
Msg-id 1355639870.4311.8.camel@vanquo.pezone.net
Whole thread Raw
Responses Re: multiple CREATE FUNCTION AS items for PLs  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: multiple CREATE FUNCTION AS items for PLs  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: multiple CREATE FUNCTION AS items for PLs  (Hannu Krosing <hannu@krosing.net>)
Re: multiple CREATE FUNCTION AS items for PLs  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
I'm going to use PL/Python as an example, but I would also like to know
if this could be applicable to other languages.

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.
While you can have them in the function definition, that means they are
executed every time the function is called, which makes it much slower.
Also, future imports are not possible this way.

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

So in practice this might look like this:

CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
import x
import y
$$,
$$
real code here
$$;

Comments?





pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Assert for frontend programs?
Next
From: Peter Eisentraut
Date:
Subject: Re: Add big fat caution to pg_restore docs regards partial db restores