PGCLIENTENCODING behavior of current CVS source

Started by Weipingover 21 years ago6 messagesgeneral
Jump to latest
#1Weiping
laser@qmail.zhengmai.net.cn

hi,
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

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Weiping (#1)
Re: PGCLIENTENCODING behavior of current CVS source

Weiping <laser@qmail.zhengmai.net.cn> writes:

[ 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

#3günter strubinsky
strubinsky@acm.org
In reply to: Tom Lane (#2)
Re: PGCLIENTENCODING behavior of current CVS source

I hate to ask for a restriction of the 1st ammendment, but the life of
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
<strubinsky@acm.org>

#4Peter Eisentraut
peter_e@gmx.net
In reply to: Tom Lane (#2)
Re: PGCLIENTENCODING behavior of current CVS source

Am Dienstag, 16. November 2004 16:11 schrieb Tom Lane:

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/

#5günter strubinsky
strubinsky@acm.org
In reply to: Weiping (#1)
Re: PGCLIENTENCODING behavior of current CVS source

No problem, I replied to save typing the email addresses and forgot to
remove the subject!

*You are fine + I apologize*! I just got sooo tired of the
'professionalism' that seems to take over and you were 'the lucky
winner' whom I abused as the address template.. 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)

gs

Weiping wrote:

guenter strubinsky wrote:

I hate to ask for a restriction of the 1st ammendment, but the life
of 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.

pardon, but what's the problem of my post, or it's yours?

--

With kind regards

signature

günter strubinsky
*email: *strubinsky@acm.org <mailto:strubinsky@acm.org>
Web: http://www.itcons.us

"They who would give up an essential liberty for temporary security,
deserve neither liberty or security" Benjamin Franklin

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
system manager. This message may contain confidential information and is
intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail

Attachments:

Object1image/gif; name=Object1Download
#6Tom Lane
tgl@sss.pgh.pa.us
In reply to: günter strubinsky (#5)
Re: PGCLIENTENCODING behavior of current CVS source

guenter strubinsky <strubinsky@acm.org> writes:

... 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