On Tue, 12 Aug 2003, Tom Lane wrote: > Stephan Szabo <[EMAIL PROTECTED]> 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)? ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
