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
|
Список | 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 по дате отправления: