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 <wulc...@wulczer.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 >
