Re: Deprecate custom encoding conversions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Deprecate custom encoding conversions
Дата
Msg-id 1685947.1606960055@sss.pgh.pa.us
обсуждение исходный текст
Ответ на RE: Deprecate custom encoding conversions  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Ответы Re: Deprecate custom encoding conversions  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Deprecate custom encoding conversions