Re: plpython issue with Win64 (PG 9.2)

Thank you. Please do let me know once fix check-in. I will test it and
share feedback with you. Thanks.

Best Regards,
Asif Naeem

On Fri, Jun 29, 2012 at 3:36 AM, Jan Urbański <wulczer(at)wulczer(dot)org> wrote:

> On 27/06/12 13:57, Jan Urbański wrote:
>
>> On 27/06/12 11:51, Asif Naeem wrote:
>>
>>> Hi,
>>>
>>> On Windows 7 64bit, plpython is causing server crash with the following
>>> test case i.e.
>>>
>>> CREATE PROCEDURAL LANGUAGE 'plpython3u';
>>>
>>>> CREATE OR REPLACE FUNCTION pymax (a integer, b integer)
>>>> RETURNS integer
>>>> AS $$
>>>> if a> b:
>>>> return a
>>>> return b
>>>> $$ LANGUAGE plpython3u;
>>>> SELECT pymax(1, 2);
>>>>
>>>
>>
>>> I think primary reason that trigger this issue is when Function
>>> PLyUnicode_Bytes() calls "PyUnicode_AsEncodedString( ,WIN1252 /*Server
>>> encoding*/, ) " it fails with null. I built latest pg 9.2 source code
>>> with
>>> python 3.2.2.3 by using Visual Studio 2010. Thanks.
>>>
>>
>> I'll try to reproduce this on Linux, which should be possible given the
>> results of your investigation.
>>
>
> Your analysis is correct, I managed to reproduce this by injecting
>
> serverenc = "win1252";
>
> into PLyUnicode_Bytes. The comment in that function says that Python
> understands all PostgreSQL encoding names except for SQL_ASCII, but that's
> not really true. In your case GetDatabaseEncodingName() returns "WIN1252"
> and Python accepts "CP125".
>
> I'm wondering how this should be fixed. Just by adding more special cases
> in PLyUnicode_Bytes?
>
> Even if we add a switch statement that would convert PG_WIN1250 into
> "CP1250", Python can still raise an exception when encoding (for various
> reasons). How about replacing the PLy_elog there with just an elog? This
> loses traceback support and the Python exception message, which could be
> helpful for debugging (something like "invalid character <foo> for encoding
> cp1250"). OTOH, I'm uneasy about invoking the entire PLy_elog machinery
> from a function that's as low-level as PLyUnicode_Bytes.
>
> Lastly, we map SQL_ASCII to "ascii" which is arguably wrong. The function
> is supposed to return bytes in the server encoding, and under SQL_ASCII
> that probably means we can return anything (ie. use any encoding we deem
> useful). Using "ascii" as the Python codec name will raise an error on
> anything that has the high bit set.
>
> So: I'd add code to translate WINxxx into CPxxx when choosing the Python
> to use, change PLy_elog to elog in PLyUnicode_Bytes and leave the SQL_ASCII
> case alone, as there were no complaints and people using SQL_ASCII are
> asking for it anyway.
>
> Cheers,
> Jan
>