Re: 9.3 RC1 psql encoding reporting inconsistently?

From: David Johnston <polobo(at)yahoo(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: 9.3 RC1 psql encoding reporting inconsistently?
Date: 2013-09-03 00:33:52
Message-ID: 1378168432162-5769339.post@n5.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane-2 wrote
> Michael Nolan &lt;

> htfoot@

> &gt; writes:
>> This is 9.3 RC1 on a Fedora 7 system. Why does \l report the encoding
>> as SQL_ASCII and \set report it as UTF8?
>
> psql sets client_encoding based on its environment (LANG or related
> variables). That's been true for some time --- since 9.1, according
> to a quick check.
>
> regards, tom lane

My knowledge of encoding is minimal but to expand on the comment:

Client and server (or, more specifically, database) encodings can and often
do differ just as you are seeing here.

I'm guessing that somewhere deep inside psql and/or postgres encoding
conversion is performed if the client and server do not match. While I
guess it is possible to try and auto-adapt the client encoding to match the
server/database the current policy is to require the user to explicitly (so
to speak) declare the encoding they are using on their client.

I guess a counter-question would be: what would you expect "\set" to report
and why?

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/9-3-RC1-psql-encoding-reporting-inconsistently-tp5769334p5769339.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-09-03 01:23:54 Re: dynamic shared memory
Previous Message Bruce Momjian 2013-09-03 00:17:22 Re: [v9.4] row level security