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

From Tom Lane
Subject Re: Deprecate custom encoding conversions
Date
Msg-id 1685947.1606960055@sss.pgh.pa.us
Whole thread Raw
In response to RE: Deprecate custom encoding conversions  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Responses Re: Deprecate custom encoding conversions
List pgsql-hackers
"tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com> writes:
> From: Heikki Linnakangas <hlinnaka@iki.fi>
>> 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
thatuse CREATE CONVERSION to handle external characters.  So, I think we may as well retain it.  (OTOH, I'm wondering
howother DBMSs support external characters and what Postgres should implement it.) 

I recall a discussion in which someone explained that things are messy for
Japanese because there's not really just one version of SJIS; there are
several, because various groups extended the original standard in not-
quite-compatible ways.  In turn this means that there's not really one
well-defined conversion to/from Unicode --- which is the reason why
allowing custom conversions seemed like a good idea.  I don't know
whether anyone over there is actually using custom conversions, but
I'd be hesitant to just nuke the feature altogether.

Having said that, it doesn't seem like the conversion API is necessarily
any more set in stone than any of our other C-level APIs.  We break things
at the C API level whenever there's sufficient reason.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2
Next
From: Michael Paquier
Date:
Subject: Re: Deprecate custom encoding conversions