Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings.
От | Heikki Linnakangas |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings. |
Дата | |
Msg-id | 4FF69C36.2090803@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings. (Jan Urbański <wulczer@wulczer.org>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings
to Python encodings.
|
Список | pgsql-hackers |
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? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: