Re: PGCLIENTENCODING behavior of current CVS source

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Weiping <laser(at)qmail(dot)zhengmai(dot)net(dot)cn>
Cc: pgsql-general(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: PGCLIENTENCODING behavior of current CVS source
Date: 2004-11-16 15:11:57
Message-ID: 18777.1100617917@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Weiping <laser(at)qmail(dot)zhengmai(dot)net(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mage 2004-11-16 15:14:25 out of disk space
Previous Message Mike Cox 2004-11-16 15:01:51 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX