Re: psql weird behaviour with charset encodings - Mailing list pgsql-general

From hernan gonzalez
Subject Re: psql weird behaviour with charset encodings
Date
Msg-id t2m48692c2d1005071501z5bcab4d5q3d7cf79f23ba568b@mail.gmail.com
Whole thread Raw
In response to Re: psql weird behaviour with charset encodings  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: psql weird behaviour with charset encodings  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
It's surely not a xterm problem, I see the characters ok with just the
\x formatting. I can check also the output redirecting to a file.

My original client_encoding seems to be LATIN9 in both cases,
accorging to the \set ouput.

If I change it (for the root user) to UTF8 with " SET CLIENT_ENCODING
TO 'UTF8';  " the conversion from LATIN9 to UTF8 indeed takes place
(and I see the characters ok, by switching my terminal to UTF8).

(BTW: I understood from the  docs that  " \set ENCODING 'UTF8'; " is
equivalent but this does nothing in my case)

But I actually dont want that. I want psql to not try any charset
conversion, just give me the raw text as is stored in the db. He seems
to do this when \x is set. But it seems that he need to compute lenght
of the strings and for this he needs to use the string routines from
his own locale.

I'm uncertain yet if this is the expected behaviour.


> What's client_encoding set to in the two cases?  If it's not utf8,
> does changing it to that improve matters?  Alternatively, see what
> xterm (or whatever terminal window you're using) thinks the encoding
> is, and change it to match psql's client_encoding.
>
>                        regards, tom lane
>



--
Hernán J. González
http://hjg.com.ar/

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: psql weird behaviour with charset encodings
Next
From: Tom Lane
Date:
Subject: Re: psql weird behaviour with charset encodings