Re: Deprecate custom encoding conversions

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 had this idea while looking at the encoding conversions performed in
COPY. The current conversion functions return a null-terminated,
palloc'd string, which is a bit awkward for the callers. The caller
needs to call strlen() on the result, and it would be nice to reuse the
same buffer for all the conversions. And I've got a hunch that it'd be
faster to convert the whole 64 kB raw input buffer in one go, rather
than convert each line separately, but the current function signature
doesn't make that easy either.

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.

- Heikki