Re: [HACKERS] Implications of multi-byte support in a distribution
От | Hannu Krosing |
---|---|
Тема | Re: [HACKERS] Implications of multi-byte support in a distribution |
Дата | |
Msg-id | 37CE1EAB.7C8A7F62@trust.ee обсуждение исходный текст |
Ответ на | Re: [HACKERS] Implications of multi-byte support in a distribution (Tatsuo Ishii <t-ishii@sra.co.jp>) |
Список | pgsql-hackers |
Thomas Lockhart wrote: > > > >> That shouldn't be too difficult, if we have an encoding > > >> infomation with each text column or literal. Maybe now is the > > >> time to introuce NCHAR? > > TL> I've been waiting for a go-ahead from folks who would use > > TL> it. imho the way to do it is to use Postgres' type system to > > TL> implement it, rather than, for example, encoding "type" > > TL> information into each string. We can also define a "default > > TL> encoding" for each database as a new column in pg_database... > > What about sorting? Would it be possible to solve it in similar way? > > If I'm not mistaken, there is currently no good way to use two different > > kinds of sorting for one postmaster instance? > > 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 ? ----------------- Hannu
В списке pgsql-hackers по дате отправления: