Re: WIP: plpython3

On Fri, Jul 24, 2009 at 5:23 AM, James Pye<lists(at)jwp(dot)name> wrote:

>   That also means that maintaining a separate, parallel code base
>   for a Python 3 variant can only be acceptable if it gives major
> advantages.

I'm not particularly interested in Python 3.x support yet (we are still back on 2.4, soon to hop to 2.5 or 2.6. For us 3.1 is probably 2 years away at the earliest). I am interested in improved plpython though.

>  * Reworked function structure (Python modules, not function fragments)

I think it would be an improvement to move away from function fragments. One thing I would like to be able to do is have my Python test suite import my plpython and run tests on it. This would be much easier to do if instead of 'import Postgres' to pull in the api, an object was passed into the entry point which provides the interface to PostgreSQL. This way I can pass in a mock object. This is also useful outside of the test suite - the same module can be used as a stored procedure or by your Python application - your web application can use the same validators as your check constraints for instance.

> The second feature, function structure, is actually new to the PL.
> Originally PL/Py took a pl/python-like approach to triggers and functions.
> *Currently*, I want to change procedures to be Python modules with specific
> entry points used to handle an event. Mere invocation: "main". Or, a trigger
> event: "before_insert", "after_insert", "before_update", etc.

> So, a regular function might look like:
>
> CREATE OR REPLACE FUNCTION foo(int) RETURNS int LANGUAGE plpython3u AS
> $python$
> import Postgres
>
> def main(i):
>    return i
> $python$;
>
> Despite the signature repetition, this is an improvement for the user and
> the developer. The user now has an explicit initialization section that is
> common to Python(it's a module). The PL developer no longer needs to munge
> the source, and can work with common Python APIs to manage and introspect
> the procedure's module(...thinking: procedure settings..).

I'd like a way to avoid initialization on module import if possible. Calling an initialization function after module import, if it exists, would do this.

CREATE FUNCTION foo(int) RETURNS in LANGUAGE plpythonu AS
$python$
[initialization on module import]
def pg_init(pg):
[initialization after module import]
def pg_main(pg, i):
return i
$python$;

> Thoughts? [...it still has a *long* ways to go =]

I tend to dislike magic function names, but perhaps it is the most usable solution.

--
Stuart Bishop <stuart(at)stuartbishop(dot)net>
http://www.stuartbishop.net/