RE: Deprecate custom encoding conversions - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: Deprecate custom encoding conversions
Date
Msg-id TYAPR01MB299039CAED9FF08D526B2859FEF20@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Deprecate custom encoding conversions  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Deprecate custom encoding conversions
Re: Deprecate custom encoding conversions
List 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 by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Add docs stub for recovery.conf
Next
From: Julien Rouhaud
Date:
Subject: Re: pg_stat_statements oddity with track = all