PL/Python error checking

Поиск
Список
Период
Сортировка
От Michael Fuhr
Тема PL/Python error checking
Дата
Msg-id 20050627135323.GA94604@winnie.fuhr.org
обсуждение исходный текст
Ответы Re: PL/Python error checking  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: PL/Python error checking  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-patches
This patch addresses the problem mentioned in the "process crash
when a plpython function returns unicode" thread:

http://archives.postgresql.org/pgsql-bugs/2005-06/msg00105.php

In several places PL/Python was calling PyObject_Str() and then
PyString_AsString() without checking if the former had returned
NULL to indicate an error.  PyString_AsString() doesn't expect a
NULL argument, so passing one causes a segmentation fault.  This
patch adds checks for NULL and raises errors via PLy_elog(), which
prints details of the underlying Python exception.  The patch also
adds regression tests for these checks.  All tests pass on my
Solaris 9 box running HEAD and Python 2.4.1.

In one place the patch doesn't call PLy_elog() because that could
cause infinite recursion; see the comment I added.  I'm not sure
how to test that particular case or whether it's even possible to
get an error there: the value that the code should check is the
Python exception type, so I wonder if a NULL value "shouldn't
happen."  This patch converts NULL to "Unknown Exception" but I
wonder if an Assert() would be appropriate.

The patch is against HEAD but the same changes should be applied
to earlier versions because they have the same problem.  The patch
might not apply cleanly against earlier versions -- will the committer
take care of little differences or should I submit different versions
of the patch?

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: limiting connections per user/database
Следующее
От: Karel Zak
Дата:
Сообщение: Re: limiting connections per user/database