Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings. - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings.
Date
Msg-id 4FF69C36.2090803@enterprisedb.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings.  (Jan Urbański <wulczer@wulczer.org>)
Responses Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings.
List 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 by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: pl/perl and utf-8 in sql_ascii databases
Next
From: Jan Urbański
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings.