splitting plpython into smaller parts

Jan Urbański <wulczer@wulczer.org>

From: Jan Urbański <wulczer@wulczer.org>
To: Postgres - Hackers <pgsql-hackers@postgresql.org>
Date: 2011-11-13T17:45:25Z
Lists: pgsql-hackers

Attachments

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