pl/python refactoring

Поиск
Список
Период
Сортировка
От Jan Urbański
Тема pl/python refactoring
Дата
Msg-id 4D135170.3080705@wulczer.org
обсуждение исходный текст
Ответы Re: pl/python refactoring  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Here's the base refactoring patch mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php

Git branch for this patch: https://github.com/wulczer/postgres/tree/refactor

It does some architectural changes to PL/Python that make it easier to
implement other features, like for instance a validator function. The
full list of changes in the patch is:

  * Use HTABs keyed with OIDs for procedure and trigger caches. Using
Python dictionaries for these caches seemes like using the wrong tool,
and then you get better error reporting and memory management with PG HTABs.

  * Get rid of global error state. It was wrong, 'nuff said.

  * Fix an error when the iterator was left half-open after an error.

  * Factor out PLy_procedure_{input,output}_conversion functions.

  * Use palloc in TopMemoryContext instead of malloc. As discussed in
http://archives.postgresql.org/pgsql-hackers/2010-11/msg01857.php

  * Use PyObject_New instead of PyObject_NEW (which is undocumented).

  * Reset exception state after catching an error from SPI calls. Doing
SPI calls in subtransactions will remove the need to do that altogether,
so this little wart will go away soon.

  * Correctly put the exceptions in the plpy module. Previous coding
failed for Python 3 (the exceptions were not available on Python 3 from
the plpy module, see the new test in plpython_test.sql and also
http://archives.postgresql.org/message-id/4D0CFE5C.5060704@wulczer.org).

 * Define all fields of the PyModuleDef structure for Python 3 (see
http://docs.python.org/py3k/c-api/module.html#PyModuleDef). Not sure why
this worked at all, I guess by some lucky coincidence the undefined
fields were falling in an accessible memory region filled with zeroes...

 * Raise normal exceptions from plpy.error() instead of relying on the
global error state.

 * Do not prefix error messages with "PL/Python: ". It's redundant given
the error context.

All other PL/Python patches rely on these refactorings.

Cheers,
Jan

Вложения

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

Предыдущее
От: Pavel Golub
Дата:
Сообщение: Cannot compile Pg 9.0.2 with MinGW under Windows
Следующее
От: Jan Urbański
Дата:
Сообщение: pl/python validator function