Am 2009-09-13 um 22:07 schrieb John:
>>> I've a lot of experience with MySQL and a bit with SQLite.
>>>
>>> After all the praise for PostgreSQL on this list I tried to use it
>>> when I recently set up a new webserver.
>>>
>>> After searching the docs and the Internets for a while I had to
>>> conclude that PostgreSQL doesn't allow to use different text
>>> encodings
>>> (collations) for different tables - even worse, the encoding is
>>> hard-
>>> compiled, and UTF-8 is only possible with "C" locale.
>>> That's totally out of the question and a horribly outdated approach!
>>> So I went back to MySQL.
>>>
>>> Maybe I did or understood something wrong - but I can't say it would
>>> be easy to set up a working PostSQL server. ("Only one 8-bit
>>> encoding"
>>> *is* "not working".)
>>>
>>> Greetlings from Lake Constance!
>>> Hraban
>>> ---
>>
>> You are right about different encodings for different tables. As of
>> 8.3 you
>> can have different encodings for databases within a cluster but
>> that is far
>> as it extends at the moment. Your comments about UTF-8 are wrong
>> though.
>> See the link for a better explanation:
>> http://www.postgresql.org/docs/8.4/interactive/multibyte.html
>
> I missed that he was talking about tables and not databases.
It would be enough if I could just use UTF-8 for everything.
But I didn't manage to set that up - didn't try to compile PostgreSQL
on my own, though.
(My webserver is a vServer running Ubuntu Hardy. And I use a German
locale.)
What about this quote from the linked page (PostgreSQL version 8.4):
"""
An important restriction, however, is that each database's character
set must be compatible with the database's LC_CTYPE and LC_COLLATE
locale settings. For C or POSIX locale, any character set is allowed,
but for other locales there is only one character set that will work
correctly. (On Windows, however, UTF-8 encoding can be used with any
locale.)
"""
And on the same page for version 8.3 (that's the version on Hardy) it
reads:
"""
An important restriction, however, is that each database character set
must be compatible with the server's LC_CTYPE setting. When LC_CTYPE
is C or POSIX, any character set is allowed, but for other settings of
LC_CTYPE there is only one character set that will work correctly.
Since the LC_CTYPE setting is frozen by initdb, the apparent
flexibility to use different encodings in different databases of a
cluster is more theoretical than real, except when you select C or
POSIX locale (thus disabling any real locale awareness). It is likely
that these mechanisms will be revisited in future versions of
PostgreSQL.
"""
I understand that as "your server must run under C locale". Wrongly?
Greetlings from Lake Constance!
Hraban
---
http://www.fiee.net
https://www.cacert.org (I'm an assurer)
--- StripMime Report -- processed MIME parts ---
multipart/signed
text/plain (text body -- kept)
application/pgp-signature
---
_______________________________________________
Post Messages to: Dabo-users@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message:
http://leafe.com/archives/byMID/f9b15048-4647-4ab9-8391-3bb5e82a8...@fiee.net
