Re: [WIP] collation support revisited (phase 1)
От | Zdenek Kotala |
---|---|
Тема | Re: [WIP] collation support revisited (phase 1) |
Дата | |
Msg-id | 4877BA0F.9030704@sun.com обсуждение исходный текст |
Ответ на | Re: [WIP] collation support revisited (phase 1) (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: [WIP] collation support revisited (phase 1)
|
Список | pgsql-hackers |
Martijn van Oosterhout napsal(a): > On Thu, Jul 10, 2008 at 11:24:29PM +0200, Radek Strnad wrote: >> Hi, >> >> after long discussion with Mr. Kotala, we've decided to redesign our >> collation support proposal. >> For those of you who aren't familiar with my WIP patch and comments from >> other hackers here's the original mail: >> http://archives.postgresql.org/pgsql-hackers/2008-07/msg00019.php > > <snip> >> phase 1 >> Implement "sort of framework" so the PostgreSQL will have basic guts >> (pg_collation & pg_charset catalogs, CREATE COLLATION, add collation support >> for each type needed) and will support collation at database level. This >> phase has been accepted as a Google Summer of Code project. > > Why bother with pg_charset? I don't think I've seen anyone even asking > for multiple charsets in a single DB and certainly no actual use case. 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. If I think about it, the question is if we need both information in pg_type and so on, because collation automatically define charset. any idea? Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql
В списке pgsql-hackers по дате отправления: