Re: plpython issue with Win64 (PG 9.2)
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Jan Urbański <wulczer@wulczer.org>
Cc: Asif Naeem <asif.naeem@enterprisedb.com>,
pgsql-hackers@postgresql.org
Date: 2012-07-05T19:37:05Z
Lists: pgsql-hackers
On 04.07.2012 15:11, Jan Urbański wrote:
> On 04/07/12 13:58, Asif Naeem wrote:
>> I have test the patch on Win64. postgres server is working fine now for
>> WIN1252. Thanks.
>>
>>> create function enctest() returns text as $$
>>> return b'tr\xc3\xb3spido'.decode('**utf-8')
>>> $$ language plpython3u;
>>>
>>> select enctest(), encode(convert_to(enctest(), 'utf-8'), 'hex');
>>>
>>
>> create function enctest() returns text as $$
>> return b'tr\xc3\xb3spido'.decode('utf-8')
>> $$ language plpython3u;
>> select enctest(), encode(convert_to(enctest(), 'utf-8'), 'hex');
>> enctest | encode
>> ----------+--------------------
>> tróspido | 7472c3b3737069646f
>> (1 row)
>>
>> Please do let me know If you have any other query. Thanks.
>
> Great, this looks correct.
>
> Can we apply this to 9.2?
Committed. This bug was present in versions >= 9.0, so backpatched.
I used ereport() rather than elog() in the error message. Correct me if
that was wrong, but the point was to avoid PLy_elog(), because that
might cause recursion, and ereport() should be ok. I believe the message
should be translated, as it's quite possible to get that error, at least
if you use SQL_ASCII, so ereport() is more approriate than elog().
Thanks!
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com