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
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 |