Re: [WIP] collation support revisited (phase 1) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [WIP] collation support revisited (phase 1)
Date
Msg-id 20080711210120.GL4110@alvh.no-ip.org
Whole thread Raw
In response to Re: [WIP] collation support revisited (phase 1)  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Responses Re: [WIP] collation support revisited (phase 1)  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List 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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Change of site
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] GIN improvements