Re: [HACKERS] Implications of multi-byte support in a distribution
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] Implications of multi-byte support in a distribution |
Дата | |
Msg-id | 37CE91A4.5B065286@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Implications of multi-byte support in a distribution (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Ответы |
Re: [HACKERS] Implications of multi-byte support in a distribution
|
Список | pgsql-hackers |
> > Each encoding/character set can behave however you want. You can reuse > > collation and sorting code from another character set, or define a > > unique one. > Is it really inside one postmaster instance ? > If so, then is the character encoding defined at the create table / > create index process (maybe even separately for each field ?) or can I > specify it when sort'ing ? Yes, yes, and yes ;) I would propose that we implement the explicit collation features of SQL92 using implicit type conversion. So if you want to use a different sorting order on a *compatible* character set, then (looking up in Date and Darwen for the syntax...): 'test string' COLLATE CASE_INSENSITIVITY becomes internally case_insensitivity('test string'::text) and c1 < c2 COLLATE CASE_INSENSITIVITY becomes case_insensitivity(c1) < case_insensitivity(c2) - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
В списке pgsql-hackers по дате отправления: