Re: Multibyte encoding vs. SQL_ASCII vs. locales and European languages

Frank Joerdens <frank(at)joerdens(dot)de> writes:
> Hence my question was not "What do I gain from multibyte
> support when I don't need multibyte support?" but "what do I get from
> specifying Latin1 encoding (which is only available when compiling
> with --enable-multibyte) and what do I lose when using locales or
> sql_ascii?".

You need LOCALE support if you want smarts about sort order, case
conversion, etc. This is orthogonal to MULTIBYTE.

I was about to say that MULTIBYTE offers no value whatsoever if you
aren't using any multibyte character sets, but that's an overstatement.
One part of the MULTIBYTE feature is the ability to perform character
set conversions between what's physically stored in the server and
what's sent/received by clients. This could be of use even in a
purely European environment if you have clients who would like to use
different encodings, viz the different ISO 8859-n character sets.
Or if you want translation to/from UNICODE.

But if your clients all agree on the same single-byte character set,
I can't see that MULTIBYTE helps you.

Also, if you need client character set conversion but all the
interesting character sets are single-byte, there's a simpler feature
called CYR_RECODE that just does recoding during client I/O without
any of the internal-processing penalties that MULTIBYTE carries.
I don't think the CYR_RECODE code is as well-tested as the MULTIBYTE
code, but it'll never get there unless people use it...

regards, tom lane