From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Radek Strnad <radek(dot)strnad(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [WIP] collation support revisited (phase 1) |
Date: | 2008-07-11 21:01:20 |
Message-ID: | 20080711210120.GL4110@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Zdenek Kotala escribió:
> The example is when you have translation data (vocabulary) in database.
> But the reason is that ANSI specify (chapter 4.2) charset as a part of
> string descriptor. See below:
>
> — The length or maximum length in characters of the character string type.
> — The catalog name, schema name, and character set name of the character
> set of the character string type.
> — The catalog name, schema name, and collation name of the collation of
> the character string type.
We already support multiple charsets, and are able to do conversions
between them. The set of charsets is hardcoded and it's hard to make a
case that a user needs to create new ones. I concur with Martijn's
suggestion -- there's no need for this to appear in a system catalog.
Perhaps it could be argued that we need to be able to specify the
charset a given string is in -- currently all strings are in the server
encoding (charset) which is fixed at initdb time. Making the system
support multiple server encodings would be a major undertaking in itself
and I'm not sure that there's a point.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | chris | 2008-07-11 21:03:14 | Re: Follow-up on replication hooks for PostgreSQL |
Previous Message | Simon Riggs | 2008-07-11 20:44:06 | Change of site |