From: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
---|---|
To: | 'Heikki Linnakangas' <hlinnaka(at)iki(dot)fi> |
Cc: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Deprecate custom encoding conversions |
Date: | 2020-12-03 00:54:56 |
Message-ID: | TYAPR01MB299039CAED9FF08D526B2859FEF20@TYAPR01MB2990.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: Heikki Linnakangas <hlinnaka(at)iki(dot)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 use CREATE CONVERSION to handle external characters. So, I think we may as well retain it. (OTOH, I'm wondering how other DBMSs 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 mechanism of 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
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2020-12-03 01:00:51 | Re: pg_stat_statements oddity with track = all |
Previous Message | David G. Johnston | 2020-12-03 00:33:12 | Re: Add docs stub for recovery.conf |