On 12/07/12 11:08, Heikki Linnakangas wrote:
On 07.07.2012 00:12, Jan Urbański wrote:
On 06/07/12 22:47, Peter Eisentraut wrote:
On fre, 2012-07-06 at 18:53 +0300, Heikki Linnakangas wrote:
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.
Actually, we already do the other direction that way
(PLyUnicode_FromStringAndSize) , so maybe it would be more consistent to
always use this.
I would hesitate to use this as a kind of fallback, because then we
would sometimes be using PostgreSQL's recoding tables and sometimes
Python's recoding tables, which could became confusing.
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).
J
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
