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
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 |