|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
"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
|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|