Tatsuo Ishii 寫道：
> > For example: If we initdb -E MULE_INTERNAL first,
> > SET CLIENT_ENCODING TO 'BIG5', and
> > INSERT INTO some_table VALUES (..., 'the last byte of some Big5 char is
> > backslash\',...),
> > then we can not successfully complete this SQL INSERT -- the prompt of psql
> > changes
>
> Hum. initdb -E MULE_INTERNAL should work as well. Let me dig into the
> problem. It would be nice if you could send me the Big5 data for
> testing by a private mail.
> BTW I would not recommend "SET CLIENT_ENCODING TO 'BIG5'" to do an
> on-the-fly encoding changes. Since in this way, frontend side has no
> idea what the client encoding is. 7.0.x overcome this problem by
> introducing new \encoding command. For 6.5 or before I would recommend
> to use PGCLIENTENCODING environment variable.
You are right! When I do \encoding BIG5, it works.
But it seems that "\encoding" can only be issued in
psql's command prompt or be done with
PQsetClientEncoding() in libpq.
If our application for input is written in PHP (4.0.2)
How do we notify PostgreSQL that the frontend encoding
is 'BIG5' ? (pg_exec("\encoding BIG5") failed.)
PostgreSQL 7.1 will support automatic code conversion for
BIG5 to utf-8. Does it means that we do not have to
announce client encoding as long as the backend is utf-8?
I have also tried to set the environment variable
PGCLIENTENCODING to 'BIG5'. But when I execute
psql and then issue \encoding, it shows 'SQL_ASCII' in 7.0.2.
Is this environment variable useless in 7.0.x and latter?
Thank you so much for a newbie!
--
Chih-Chang Hsieh