PGCLIENTENCODING behavior of current CVS source
Weiping
I'm using CVS source built postgres, may be one day later
then the main site, but found one problem:
I've set PGCLIENTENCODING environment before, for easy of
typing, like export PGCLIENTENCODING=GBK in my .profile,
but after I upgrade my postgresql to current CVS, I found
problem, the database initialized using:
initdb --locale=zh_CN.utf8 ...
the database connected is UNICODE encoded, but when I
use psql to loging to one of my database, it response:
psql: FATAL: invalid value for parameter "client_encoding": "GBK"
but when I remove the PGCLIENTENCODING setting:
unset PGCLIENTENCODING,
now I can login, but when I do a:
DHY_JJG=# \dt
ERROR: invalid byte sequence for encoding "UNICODE": 0xed
but, after:
DHY_JJG=# \encoding gbk
DHY_JJG=#\dt
woule be ok. the LANG setting is zh_CN.gbk, I guess it's
a localization problem. may be the encoding of thos po files.
because while using psql -E we see the query contain the
locale string in AS clause, but don't know the best way to
fix that, may be use UNICODE to encode those po files?
regards
Laser
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majo...@postgresql.org)
Tom Lane
> [ database encoding is unicode ]
> now I can login, but when I do a:
> DHY_JJG=# \dt
> ERROR: invalid byte sequence for encoding "UNICODE": 0xed
> but, after:
> DHY_JJG=# \encoding gbk
> DHY_JJG=#\dt
> woule be ok.
This is a risk no matter what encoding is used in the client-side .po
files; as long as it's different from the current client_encoding,
there is a potential for mis-conversion and other problems. I don't
see a simple solution. In this particular case, it would help if psql's
describe commands didn't assume they could send localized column headers
to the server --- but I don't think that solves all related issues.
BTW, Peter, it seems like this may be a good argument for keeping the
client and server .po files separate. They might need different encodings.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Peter Eisentraut
> This is a risk no matter what encoding is used in the client-side .po
> files; as long as it's different from the current client_encoding,
> there is a potential for mis-conversion and other problems. I don't
> see a simple solution.
Here's the news: Not only the server encoding and the server locale have to
match. The same is true on the client side. In particular, in order to
avoid errors from the PO files, your LC_CTYPE and your PGCLIENTENCODING need
to be compatible.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
guenter strubinsky
many colleagues and mine would be much easier if those racists and
idiots would not waste our bandwidth.Nobody but them is -to my beliefs-
interested in their flaming each other.
Please knock them off the board.
with kind regards
günter strubinsky
<strub...@acm.org>
Tom Lane
> ... I've been in this list
> (on and off) since more than 3 years now. I was either off or this is
> the first time that people forget their basic communication skills
> (assuming they had those skills ever)
None of this is coming from actual list members. As far as I can tell,
it's just one net.kook who has decided to try to disrupt the list by
forging bogus mail that appears to come from list members (at least
to the list 'bot it looks that way --- you can tell the stuff is phony
by comparing the Received: headers to real mail from those people).
Ignore it, and the child will eventually get bored and go away. As long
as people keep rising to the bait, though, he'll probably keep trolling.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend