Re: Deprecate custom encoding conversions

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
Subject: Re: Deprecate custom encoding conversions
Date: 2020-12-03 04:18:51
Message-ID: df53d2bc-f399-c20b-33ca-0a177760f84c@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020/12/03 13:07, Tom Lane wrote:
> Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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 default ones.
>
>> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-12-03 04:30:08 Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly
Previous Message Tom Lane 2020-12-03 04:07:22 Re: Deprecate custom encoding conversions