Tatsuo Ishii <t-ishii@sra.co.jp> wrote:
> > > admin=# select * from SJIS_KANJI ;
> > > \: extra argument ';' ignored
> > > \: extra argument ';' ignored
> > > Invalid command \. Try \? for help.
> >
(snip)
>
> That's because none-MB client does not understand how "Shift JIS
> kanji" consists of letters with different width bytes. The similar
> problem would happen with the Big5 character set (traditional
> Chinese), also. Unlike other character sets, these should be treated
> carefully since they include the same bit patterns as ASCII and that
> makes none-MB clients confused.
Thank you for your reply.
(Probably, the direct cause of this error is PQmblen(). non-MULTIBYTE-PQmblen() always return "1". )
> Anyway, I could hardly imagine that such configurations
> would actually exist in the real world. Masaaki, could you tell me
> what are the advantages or reasons of the configuration?
# My poor English won't be able to explain the real world ;-).
If a client libpq always be made by "configure --enable-
multibute", the advantages are
1. In the case of SQL_ASCII, a client application speed is almost equal to non-MULTIBYTE. And the MULTIBYTE code
is not so larger. 2. When required, by using "set client_encoding=xxx", it is possible to use the MULTIBYTE at
anytime.
--
Regard,
SAKAIDA Masaaki -- Osaka, Japan
