From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Charlie Clark <charlie(at)begeistert(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Weird behaviour on a join with multiple keys |
Date: | 2007-03-09 23:04:12 |
Message-ID: | 4269.1173481452@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Charlie Clark <charlie(at)begeistert(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ted Byers | 2007-03-09 23:06:06 | Re: Setting week starting day |
Previous Message | Don Lavelle | 2007-03-09 22:45:14 | Re: Beginner's Questions |