From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kris Jurka <books(at)ejurka(dot)com> |
Cc: | John Sidney-Woollett <johnsw(at)wardbrook(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Unicode vs SQL_ASCII DBs |
Date: | 2004-02-02 15:11:07 |
Message-ID: | 9463.1075734667@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Kris Jurka <books(at)ejurka(dot)com> writes:
> On Mon, 2 Feb 2004, John Sidney-Woollett wrote:
>> Except that in my test, the two differently encoded databases were in the
>> same 7.4.1 cluster with the same locale, yet they sorted the *same* data
>> differently - implying the encoding is a factor.
> Right, note the "and you must choose an encoding that works with your
> locale." clause. A SQL_ASCII encoding and a UTF-8 locale don't work.
In practice, any given locale setting assumes a particular encoding and
will not work if some other encoding is used. For instance, on recent
Red Hat releases:
$ locale -a | grep ^de_DE
de_DE
de_DE.iso88591
de_DE(dot)iso885915(at)euro
de_DE.utf8
de_DE(dot)utf8(at)euro
de_DE(at)euro
I'm not too sure which encoding "de_DE" uses, but the other two are
clearly named to reflect their expected encoding.
It is really a bug that PG allows you to select incompatible locale and
encoding settings. We'd fix it if we could figure out a portable way of
determining which encoding a locale expects --- unfortunately the
standard APIs for libc omit this information ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Keith C. Perry | 2004-02-02 15:13:36 | Re: business references for postgresql |
Previous Message | Martin Marques | 2004-02-02 15:04:49 | Re: I can't upgrade to PostgreSQL 7.4 in RedHat 9.0 |