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
Re: Deprecate custom encoding conversions |
Список | 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 по дате отправления: