Re: Deprecate custom encoding conversions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>
Cc: "'Heikki Linnakangas'" <hlinnaka(at)iki(dot)fi>, 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 01:47:35
Message-ID: 1685947.1606960055@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> writes:
> From: Heikki Linnakangas <hlinnaka(at)iki(dot)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 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.)

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-12-03 01:50:40 Re: Deprecate custom encoding conversions
Previous Message Michael Paquier 2020-12-03 01:47:32 Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2