splitting plpython into smaller parts

Поиск
Список
Период
Сортировка
От Jan Urbański
Тема splitting plpython into smaller parts
Дата
Msg-id 4EC00235.5070902@wulczer.org
обсуждение исходный текст
Ответы Re: splitting plpython into smaller parts  (Greg Smith <greg@2ndQuadrant.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: why do we need two snapshots per query?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: why do we need two snapshots per query?