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-06T15:53:55Z
Lists: pgsql-hackers
On 06.07.2012 18:01, Jan Urbański wrote: > There's still trouble with EUC_TW and MULE_INTERNAL which don't have > Python equivalents. EUC-TW has been discussed in > http://bugs.python.org/issue2066 and rejected (see > http://bugs.python.org/issue2066#msg113731). > > If you use any of these encodings, you *will* get into the recursion > trouble described eariler, just as before the path you'd get into it > with CP1252 as your encoding. > > What shall we do about those? Ignore them? Document that if you're sing > one of these encodings then PL/Python with Python 2 will be crippled and > with Python 3 just won't work? We could convert to UTF-8, and use the PostgreSQL functions to convert from UTF-8 to the server encoding. Double conversion might be slow, but I think it would be better than failing. -- 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