ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> The attached is the second plan. It uses UTF-8 and locale=C when
> the default locale encoding is not supported and none of encoding and
> locale are passed to initdb. It would help users who use the default
> settings (including regression test).
I'm not very happy with this proposal, because for people who don't
actually care about non-ASCII data (which is still a lot of people),
forcing UTF-8 as the default encoding will impose pretty substantial
overhead compared to SQL_ASCII --- it turns on all those
multibyte-encoding checks.
Implicitly selecting --no-locale doesn't seem like a big step forward
either, since then you've just given up whatever you might have learned
from the locale setting. Besides, if that's the behavior the user
wants, he can specify it.
I still think that what we should try to do in the default case is find
a locale that is the same language but UTF-8 encoding.
> At the moment, it reset all of lc_* variables, but it might be possible
> use the default locale at lc_messages, lc_monetary, lc_numeric and lc_time
> even if lc_collate and lc_ctype are reset to C.
Well, that just leaves me wondering what encoding the localized messages
would be presented in ...
regards, tom lane
