Re: client encoding name normalization in psycopg 2.4 - Mailing list psycopg

From Daniele Varrazzo
Subject Re: client encoding name normalization in psycopg 2.4
Date
Msg-id BANLkTik0aibtpsuHqhLbKP4pRuF+tc0LPw@mail.gmail.com
Whole thread Raw
In response to client encoding name normalization in psycopg 2.4  (Peter Eisentraut <peter_e@gmx.net>)
List psycopg
2011/4/7 Peter Eisentraut <peter_e@gmx.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

psycopg by date:

Previous
From: Mark Sienkiewicz
Date:
Subject: Re: portable DBAPI auto-increment
Next
From: "Eric Snow"
Date:
Subject: Problem with error handling