Re: Deprecate custom encoding conversions

Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> On 02/12/2020 18:18, Tom Lane wrote:
>> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
>>> 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.

>> While I agree that it's probably not that useful, what would we gain
>> by removing it? If you intend to remove those catalogs, what lookup
>> mechanism would replace them? We can't exactly drop the encoding
>> conversion functionality.

> I'm thinking of replacing the catalog with a hard-coded 2D array of
> function pointers. Or something along those lines.

I like the current structure in which the encoding functions are in
separate .so's, so that you don't load the ones you don't need.
It's not real clear how to preserve that if we hard-code things.

> So I'm looking for refactoring the conversion routines to be more
> convenient for the callers. But the current function signature is
> exposed at the SQL level, thanks to CREATE CONVERSION.

I'd be the first to agree that the current API for conversion functions is
not terribly well-designed. But what if we just change it? That can't be
any worse of a compatibility hit than removing CREATE CONVERSION
altogether.

regards, tom lane