RE: Deprecate custom encoding conversions

Поиск
Список
Период
Сортировка
От tsunakawa.takay@fujitsu.com
Тема RE: Deprecate custom encoding conversions
Дата
Msg-id TYAPR01MB299039CAED9FF08D526B2859FEF20@TYAPR01MB2990.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Deprecate custom encoding conversions  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Deprecate custom encoding conversions  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Deprecate custom encoding conversions  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
From: Heikki Linnakangas <hlinnaka@iki.fi>
> I propose that we add a notice to the CREATE CONVERSION docs to say that
> it is deprecated, and remove it in a few years.
> 
> Any objections? Anyone using custom encoding conversions in production?

I can't answer deeper questions because I'm not familiar with character sets, but I saw some Japanese web articles that
useCREATE CONVERSION to handle external characters.  So, I think we may as well retain it.  (OTOH, I'm wondering how
otherDBMSs support external characters and what Postgres should implement it.)
 

Also, the SQL standard has CREATE CHARACTER SET and CREATE TRANSLATION.  I don't know how these are useful, but the
mechanismof CREATE CONVERSION can be used to support them.
 


CREATE CHARACTER SET <character set name> [ AS ]

<character set source> [ <collate clause> ]


CREATE TRANSLATION <transliteration name> FOR <source character set specification>

TO <target character set specification> FROM <transliteration source>


Regards
Takayuki Tsunakawa


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Add docs stub for recovery.conf
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: pg_stat_statements oddity with track = all