Re: [WIP] collation support revisited (phase 1)
От | Alvaro Herrera |
---|---|
Тема | Re: [WIP] collation support revisited (phase 1) |
Дата | |
Msg-id | 20080711210120.GL4110@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: [WIP] collation support revisited (phase 1) (Zdenek Kotala <Zdenek.Kotala@Sun.COM>) |
Ответы |
Re: [WIP] collation support revisited (phase 1)
|
Список | 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 по дате отправления: