Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings.
От | Jan Urbański |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings. |
Дата | |
Msg-id | 4FF69E7F.4040700@wulczer.org обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings. (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings
to Python encodings.
|
Список | pgsql-hackers |
On 06/07/12 10:05, Heikki Linnakangas wrote: > On 06.07.2012 00:54, Jan Urbański wrote: >> On 05/07/12 23:30, Peter Eisentraut wrote: >>> On tor, 2012-07-05 at 22:53 +0200, Jan Urbański wrote: >>>> The problem is that PLyUnicode_Bytes is (via an ifdef) used as >>>> PyString_ToString on Python3, which means that there are numerous call >>>> sites and new ones might appear in any moment. I'm not that keen on >>>> invoking the traceback machinery on low-level encoding errors. >>> >>> Why not? >> >> Because it can lead to recursion errors, like the one this patch was >> supposed to fix. The traceback machinery calls into the encoding >> functions, because it converts Python strings (like function names) into >> C strings. > > In the backend elog routines, there is a global variable > 'recursion_depth', which is incremented when an error-handling routine > is entered, and decremented afterwards. Can we use a similar mechinism > in PLy_elog() to detect and stop recursion? I guess we can, I'll try to do some tests in order to see if there's an easy user-triggereable way of causing PLy_elog to recurse and if not then a guard like this should be enough as a safety measure against as yet unknown conditions (as opposed to something we expect to happen regularly). Cheers, Jan
В списке pgsql-hackers по дате отправления: