Re: client libpq multibyte support

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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 any time.

--
Regard,
SAKAIDA Masaaki -- Osaka, Japan