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

Re: Encoding problems

From: "Bjarni Ragnarsson" <bjarnir(at)gmail(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: Encoding problems
Date: 2007-03-23 13:20:31
Message-ID: 938bcd6f0703230620w20327cfi47e804f540b64a33@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-admin
Hi

For those having the same problem .....
1. You need to change the codepage in shell/command prompt to 1252
(chcp 1252) and set the window to use truetype font to have it
displayed correctly.
2. Execute "set client_encoding='win1252';" to have the translation
working properly from the shell.  How you execute this statement
depends on what you're doing....

For Django users: Django doesn't send client_encoding to the database
so you need to do that manually.  Do step 1 before executing
"manage.py shell" (probably the same with dbshell) and then do the
following:

from django.db import connection
c=connection.cursor()
c.execute("set client_encoding to 'win1252';")

After that you can work with the models and use save() etc.... That
worked for me.

Best regards,
Bjarni Ragnarsson

On 3/23/07, Bjarni Ragnarsson <bjarnir(at)gmail(dot)com> wrote:
> Hi everyone.
>
> Previous message needed some rethinking and was sent like that by my mistake.
>
> From what I figured out now: pgAdmin is using Unicode as the client
> setting no matter what the database is set to.  The database was set
> to win1252.   A comment in the settings file states that
> client_encoding would default to database settings.   But pgAdmin uses
> Unicode as client_encoding unless set explicitly.   Problem solved.
> As a newbie in PostgreSQL I cannot tell if this is a bug....
>
> Another problem I was and am still having is communicating with
> PostgreSQL via the shell (cmd prompt).  The shell uses cp850 and
> PostgreSQL doesn's seem to support that by default according to the
> docs.  How do I go about dealing with that?
>
> Best regards,
> Bjarni Ragnarsson
>
> On 3/22/07, Ivo Rossacher <rossacher(at)bluewin(dot)ch> wrote:
> > show client_encoding  displays the encoding to which the server currently is
> > converting. With set client_encoding to UNICODE; you can change the
> > client_encoding on the fly and check if the results becomes better. I am not
> > sure how to adjust the client_encoding in pgAdmin so that this will be set at
> > startup automtically. There is a default client_encoding stored in the server
> > as well but there you have to check if it interfers with your other
> > interfaces.
> >
> > Best regards
> > Ivo
> >
> > Am Donnerstag, 22. März 2007 14:07 schrieb Bjarni Ragnarsson:
> > > Hi everyone.
> > >
> > > I have some encoding problems like many others.
> > >
> > > I'm using Python (and Django) with my PostgreSQL  8.2 and pgAdmin
> > > 1.6.2 on Windows XP Pro.  The default encoding here in Iceland is
> > > win1252.  I have a database with that encoding.
> > >
> > > The problem is that pgAdmin seems to use utf8 no matter what I do.
> > > The data seems to be stored correctly when entered via a web-page, but
> > > when displayed via pgAdmin it's corrupted (that is the special
> > > characters don't show correctly).  pgAdmin seems to presume the data
> > > is in utf8 format despite the database settings.  Entering data via
> > > pgAdmin results in corrupted data on the web likewise.
> > >
> > > Is this a bug or is there some setting I've overlooked?
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 9: In versions below 8.0, the planner will ignore your desire to
> > >        choose an index scan if your joining column's datatypes do not
> > >        match
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: Don't 'kill -9' the postmaster
> >
>

In response to

pgsql-admin by date

Next:From: Warren LittleDate: 2007-03-23 14:55:35
Subject: vacuum to cleanup transaction wrap around
Previous:From: SUBASH CHANDRA MOHAPATRADate: 2007-03-23 11:23:57
Subject: Pls exclude me from the mailing list

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