Re: Encoding problems

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
>