Skip site navigation (1) Skip section navigation (2)

Re: client encoding name normalization in psycopg 2.4

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 (view raw or flat)
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

In response to

psycopg by date

Next:From: Eric SnowDate: 2011-04-23 01:56:13
Subject: Problem with error handling
Previous:From: Mark SienkiewiczDate: 2011-04-11 18:29:35
Subject: Re: portable DBAPI auto-increment

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group