Weiping <laser@xxxxxxxxxxxxxxxxxxxxx> 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
---------------------------(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
