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
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

In response to

Browse psycopg by date

  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