Deprecate custom encoding conversions

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Deprecate custom encoding conversions
Дата
Msg-id 0e837cc7-42a0-7095-9611-51ed0abb2867@iki.fi
обсуждение исходный текст
Ответы Re: Deprecate custom encoding conversions  (Tom Lane <tgl@sss.pgh.pa.us>)
RE: Deprecate custom encoding conversions  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Re: Deprecate custom encoding conversions  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список pgsql-hackers
Hi,

PostgreSQL allows writing custom encoding conversion functions between 
any character encodings, using the CREATE CONVERSION command. It's 
pretty flexible, you can define default and non-default conversions, and 
the conversions live in schemas so you can have multiple conversions 
installed in a system and you can switch between them by changing 
search_path.

However:

We never use non-default conversions for anything. All code that 
performs encoding conversions only cares about the default ones.

I think this flexibility is kind of ridiculous anyway. If a built-in 
conversion routine doesn't handle some characters correctly, surely we 
should fix the built-in function, rather than provide a mechanism for 
having your own conversion functions. If you truly need to perform the 
conversions differently than the built-in routines do, you can always 
perform the conversion in the client instead.

Note that we don't support adding completely new custom encodings, all 
this is just for conversions between the built-in encodings that we have.

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?

- Heikki



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: Additional improvements to extended statistics
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: SELECT INTO deprecation