Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings.
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Jan Urbański <wulczer@wulczer.org>
Cc: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgreSQL.org>, Asif Naeem <asif.naeem@enterprisedb.com>
Date: 2012-07-18T15:17:20Z
Lists: pgsql-hackers
On 14.07.2012 17:50, Jan Urbański wrote: > On 13/07/12 13:38, Jan Urbański wrote: >> On 12/07/12 11:08, Heikki Linnakangas wrote: >>> On 07.07.2012 00:12, Jan Urbański wrote: >>>> So you're in favour of doing unicode -> bytes by encoding with UTF-8 >>>> and >>>> then using the server's encoding functions? >>> >>> Sounds reasonable to me. The extra conversion between UTF-8 and UCS-2 >>> should be quite fast, and it would be good to be consistent in the way >>> we do conversions in both directions. >>> >> >> I'll implement that than (sorry for not following up on that eariler). > > Here's a patch that always encodes Python unicode objects using UTF-8 > and then uses Postgres's internal functions to produce bytes in the > server encoding. Thanks. If pg_do_encoding_conversion() throws an error, you don't get a chance to call Py_DECREF() to release the string. Is that a problem? If an error occurs in PLy_traceback(), after incrementing recursion_depth, you don't get a chance to decrement it again. I'm not sure if the Py* function calls can fail, but at least seemingly trivial things like initStringInfo() can throw an out-of-memory error. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix mapping of PostgreSQL encodings to Python encodings.
- b66de4c6d720 9.3.0 cited