RE: Deprecate custom encoding conversions

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

In response to

Responses

Browse pgsql-hackers by date

  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