On Tue, 12 Aug 2003, Tom Lane wrote:
> Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> > Okay, I see it with en_US.UTF-8, but not with C locale, nor with
> > en_US or en_US.iso885915. It looks like the comparison rules are
> > different between the locales (and I'm not sure if SQL_ASCII encoding
> > and a UTF8 locale makes sense in practice).
>
> I'd think not --- the byte sequence is most likely not a valid string in
> UTF8 encoding. I'm not sure what strcoll() would do when comparing
> illegal byte sequences, but failing to detect that they're different is
> certainly not too implausible.
That's what I was worried about.
> This brings up once again the question of whether initdb ought to accept
> the locale it finds in the environment. I had not realized that Red Hat
> 9 is defaulting to en_US.UTF-8. That is an actively evil choice for us
> (unless we change the default database encoding to match).
That's somewhat interesting too, because my server is also RHL9,
but it appears to default accounts to en_US.iso885915. I think
there might have been a set up option relating to using UTF8 locales.
> IIRC we were about evenly split between changing or not changing
> initdb's behavior, but if this really is a typical RHL9 setup, I think
> that has got to affect the decision.
I don't know enough about the issues involved. Can we reasonably tell
that a particular locale and encoding don't make sense together (apart
from things like looking for UTF-8 in the name for example)?