From: | Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | psycopg(at)postgresql(dot)org |
Subject: | Re: client encoding name normalization in psycopg 2.4 |
Date: | 2011-04-18 16:39:28 |
Message-ID: | BANLkTik0aibtpsuHqhLbKP4pRuF+tc0LPw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | psycopg |
2011/4/7 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> Psycopg 2.4 now tries to map the PostgreSQL client encoding to a Python
> codec. But it fails to consider some variant spellings. For example, I
> have
>
> PGCLIENTENCODING=UTF-8
>
> in my environment, which completely breaks the new psycopg version with
>
> no Python codec for client encoding 'UTF-8'
>
> (The underlying reason for this is that I use
>
> export PGCLIENTENCODING=$(locale charmap)
>
> which gives variant spelling of encoding names across operating
> systems.)
>
> The PostgreSQL backend normalizes an encoding name by removing all
> non-alnum characters from it. I suggest psycopg do the same.
Oddly enough, the recent commit that has broken the JDBC driver (with
the server canonicalizing the encoding name) would have made psycopg
2.4 work correctly, as it would have received back from the server one
of the expected encoding names (reference:
http://archives.postgresql.org/pgsql-hackers/2011-04/msg00882.php)
About this issue, I've tested psycopg devel (the soon-to-be-released
2.4.1) with a 9.1 head server and there is no problem to report with
this combination (beside fixing the 2.4 problems with currently
released server versions).
-- Daniele
From | Date | Subject | |
---|---|---|---|
Next Message | Eric Snow | 2011-04-23 01:56:13 | Problem with error handling |
Previous Message | Mark Sienkiewicz | 2011-04-11 18:29:35 | Re: portable DBAPI auto-increment |