Rod Taylor <rod.tay...@gmail.com> writes: > Agreed with it being an interesting choice of settings. Nearly all of > the data is 7-bit ASCII and what isn't seems to be a mix of UTF8, > LATIN1, and LATIN15.
> I'm pretty sure it interpreted en_US to be LATIN1. There haven't been > any noticeable changes in sorting order that I know of. Well, if you've got non-ASCII data that you know is not UTF8, then setting a UTF8-dependent locale setting is a really really bad idea :-(. You are risking not just bad performance but seriously bad misbehavior. If you use a LATIN-n (or other single-byte-encoding) locale, the worst that data in other encodings can do to you is sort into odd positions. If you use a UTF8 locale and have data of other encodings, then strcoll() can tell that you are violating the encoding spec, and on many platforms it goes entirely berserk when you do that. glibc in particular does not play nice with that. You didn't say what platform this is, but if it's glibc based then you are sitting on a ticking time bomb, and you had better dump and reinitialize in a safer locale setting before your data gets eaten. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers