Re: OCTET_LENGTH is wrong
От | Tatsuo Ishii |
---|---|
Тема | Re: OCTET_LENGTH is wrong |
Дата | |
Msg-id | 20011124093222Y.t-ishii@sra.co.jp обсуждение исходный текст |
Ответ на | Re: OCTET_LENGTH is wrong (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: OCTET_LENGTH is wrong
|
Список | pgsql-hackers |
> > Yes. Consider you have UNICODE database and want to sort by French or > > whatever LATIN locale. > > > > SELECT * FROM t1 ORDER BY convert(text_column,'LATIN1'); > > > > would be the only way to accomplish that. > > I don't think so. The sort order is independent of the character > encoding, and vice versa. It must be, because > > 1) One language can be represented in different encodings and should > obviously still sort the same. > > 2) One encoding can serve for plenty of languages, which all sort > differently. I assume you are talking about the concept of SQL92/99's COLLATE syntax. But I just talked about what we could do in 7.2 which apprarently does not have the SQL92's COLLATE syntax. BTW, > I don't think so. The sort order is independent of the character > encoding, and vice versa. It must be, because This seems different from SQL's CREATE COLLATION syntax. From SQL99's CREATE COLLATION definition: CREATE COLLATION <collation name> FOR <character set specification> FROM <existingcollation name> [ <pad characteristic> ] So it seems a collation depends on a character set. -- Tatsuo Ishii
В списке pgsql-hackers по дате отправления: