Deprecate custom encoding conversions

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
Subject: Deprecate custom encoding conversions
Date: 2020-12-02 16:04:11
Message-ID: 0e837cc7-42a0-7095-9611-51ed0abb2867@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2020-12-02 16:14:11 Re: SELECT INTO deprecation
Previous Message Dean Rasheed 2020-12-02 15:51:29 Re: Additional improvements to extended statistics