splitting plpython into smaller parts

From: Jan Urbański <wulczer(at)wulczer(dot)org>
To: Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: splitting plpython into smaller parts
Date: 2011-11-13 17:45:25
Message-ID: 4EC00235.5070902@wulczer.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

attached are two incremental patches that refactor plpython into smaller
modules.

The first one factors out some bolerplate related to executing SPI
functions in subtransactions (and idea borrowed from pltcl.c).

The second one is the actual split. plpython.c has been split into 11
separate files and one header. The separate files are:

* plpython.c - top-level handlers and stuff that everything else uses
* plpython_io.c - transforming Python objects to PG structures and
vice versa
* plpython_procedure.c - handling and caching PLyProcedure objects
* plpython_exec.c - actually executing the Python code
* plpython_plpy.c - defining the global plpy module and setting up the
Python interpreter
* plpython_spi.c - interface to SPI functions
* plpython_result.c, plpython_plan.c, plpython_subtrasaction.c - a
file per Python class created by plpython with their method definitions
* plpython_functions.c - Python functions available from the plpy module
* plpython_elog.c - transforming Python errors into Postgres elogs

All regression tests pass, I tested on Python 2.3, 2.7 and 3.1.

The other plpython patch I submitted (cursor support) is not included
here. If it gets accepted, I'll update this patch to add a
plpython_cursor.c file. If this gets accepted first, I'll update the
cursor patch accordingly.

There's still a lot of room for refactoring and getting rid of
repetitive code from plpython, but that split should be fundamental to
make it a bit more manageable (it's almost 5K lines now).

I've tried to change as little code as possible during the split, apart
from making a bunch of functions non-static I only had to change the
type initialization to call functions from the
plpython_{result,plan,...} modules to avoid exposing the PyTypeObject
structs outside of their respective files and get rid of the
is_PLyPlanObject macro in favour of a function.

Cheers,
Jan

PS: the patches are gzipped because they're rather big - 270K uncompressed.

J

PPS: I guess a README in the plpython dir would be in order. If we
accept these patches, I'll write one up based on the contents of this mail.

J

Attachment Content-Type Size
0001-Factor-out-some-boilerplate-for-using-SPI-in-subtran.patch.gz application/gzip 2.0 KB
0002-Split-plpython-into-several-smaller-modules.patch.gz application/gzip 57.9 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-11-13 17:57:25 Re: why do we need two snapshots per query?
Previous Message Robert Haas 2011-11-13 17:32:08 Re: why do we need two snapshots per query?