Re: Deprecate custom encoding conversions - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Deprecate custom encoding conversions
Date
Msg-id df53d2bc-f399-c20b-33ca-0a177760f84c@oss.nttdata.com
Whole thread Raw
In response to Re: Deprecate custom encoding conversions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 2020/12/03 13:07, Tom Lane wrote:
> Fujii Masao <masao.fujii@oss.nttdata.com> writes:
>> On 2020/12/03 1:04, Heikki Linnakangas wrote:
>>> We never use non-default conversions for anything. All code that performs encoding conversions only cares about the
defaultones.
 
> 
>> Yes. I had to update pg_conversion.condefault directly so that we can
>> use custom encoding when I registered it. The direct update of
>> pg_conversion is of course not good thing. So I was wondering
>> if we should have something like ALTER CONVERSION SET DEFAULT.
> 
> Perhaps, but what I'd think is more urgent is having some way for
> a session to select a non-default conversion for client I/O.

+1

What about adding new libpq parameter like encoding_conversion
(like client_encoding) so that a client can specify what conversion to use?
That setting is sent to the server while establishing the connection.
Probably we would need to verify that the setting of this new parameter
is consistent with that of client_encoding.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Deprecate custom encoding conversions
Next
From: "Joel Mariadasan (jomariad)"
Date:
Subject: pg_ctl.exe file deleted automatically