Charlie Clark <charlie@begeistert.org> writes:
> Am 09.03.2007 um 16:15 schrieb Tom Lane:
>> There's your problem right there. The string comparison routines are
>> built on strcoll(), which is going to expect UTF8-encoded data because
>> of the LC_COLLATE setting. If there are any high-bit-set LATIN1
>> characters in the database, they will most likely look like invalid
>> encoding to strcoll(), and on most platforms that causes it to behave
>> very oddly. You need to keep lc_collate (and lc_ctype) in sync with
>> server_encoding.
> That does indeed seem to have been the problem even though the
> examples I was looking at were all using plain ASCII characters. Glad
> to know it wasn't a bug and to have learned something new.
Well, it *is* a bug: we really shouldn't let you select incompatible
locale and encoding settings. This gotcha has been known for a long
time, but it's not clear that there's a bulletproof, portable way to
determine which encoding a particular locale setting implies ...
regards, tom lane
