Re: client encoding name normalization in psycopg 2.4
От | Daniele Varrazzo |
---|---|
Тема | Re: client encoding name normalization in psycopg 2.4 |
Дата | |
Msg-id | BANLkTik0aibtpsuHqhLbKP4pRuF+tc0LPw@mail.gmail.com обсуждение исходный текст |
Ответ на | client encoding name normalization in psycopg 2.4 (Peter Eisentraut <peter_e@gmx.net>) |
Список | 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 по дате отправления: