Re: client libpq multibyte support

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