Re: Deprecate custom encoding conversions

On 02/12/2020 18:18, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.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