Thank you. Please do let me know once fix check-in. I will test it and
share feedback with you. Thanks.
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:
>>> 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
>>> python 18.104.22.168 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.
In response to
pgsql-hackers by date
|Next:||From: Boszormenyi Zoltan||Date: 2012-06-29 15:02:08|
|Subject: Re: [v9.3] Extra Daemons (Re: elegant and effective way
for running jobs inside a database)|
|Previous:||From: Kohei KaiGai||Date: 2012-06-29 14:44:32|
|Subject: Re: [v9.3] Extra Daemons (Re: elegant and effective way for
running jobs inside a database)|