Re: client libpq multibyte support

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> For the Tom's comment of "the MULTIBYTE code is a good deal larger and
> slower": IMHO it's a price of i18n (I don't claim my implementation of
> MB is the most efficient one, though). Today almost any OS and
> applications are evolving to be "i18n ready."

True, and in fact most of the performance problem in the client-side
MULTIBYTE code comes from the fact that it's not designed-in, but tries
to be a minimally intrusive patch. I think we could make it go faster
if we accepted that it was standard functionality. So I'm not averse to
going in that direction in the long term ... but I do object to turning
on MULTIBYTE by default just a couple days before release. We don't
really know how robust the MULTIBYTE-client-and-non-MULTIBYTE-server
combination is, and so I'm afraid to make it the default configuration
with hardly any testing.

regards, tom lane