Re: [HACKERS] Implications of multi-byte support in a distribution
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] Implications of multi-byte support in a distribution |
Дата | |
Msg-id | 37CC95B4.4501F393@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 |
> 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? I've been waiting for a go-ahead from folks who would use it. imho the way to do it is to use Postgres' type system to implement it, rather than, for example, encoding "type" information into each string. We can also define a "default encoding" for each database as a new column in pg_database... > BTW, it is interesting that people does not hesitate to enable > with-locale option even if they only use ASCII. I guess the > performance degration by enabling locale is not too small. Red Hat built their RPMs with locale enabled, and there is a significant performance hit. Implementing NCHAR would be a better solution, since the user can choose whether to use SQL_TEXT or the locale-specific character set at run time... - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
В списке pgsql-hackers по дате отправления: