Re: confusing / inefficient "need_transcoding" handling in copy

From: Sutou Kouhei <kou(at)clear-code(dot)com>
To: michael(at)paquier(dot)xyz
Cc: andres(at)anarazel(dot)de, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org, ishii(at)sraoss(dot)co(dot)jp
Subject: Re: confusing / inefficient "need_transcoding" handling in copy
Date: 2024-12-06 07:20:42
Message-ID: 20241206.162042.434236683509293328.kou@clear-code.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Michael,

ping.

(Do you think that this patch is still needed?)

Thanks,
--
kou

In <20240214(dot)114608(dot)2091541942684063981(dot)kou(at)clear-code(dot)com>
"Re: confusing / inefficient "need_transcoding" handling in copy" on Wed, 14 Feb 2024 11:46:08 +0900 (JST),
Sutou Kouhei <kou(at)clear-code(dot)com> wrote:

> Hi,
>
> In <ZcvlgMEjt3qY8eiL(at)paquier(dot)xyz>
> "Re: confusing / inefficient "need_transcoding" handling in copy" on Wed, 14 Feb 2024 06:56:16 +0900,
> Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
>> We have a couple of non-ASCII characters in the tests, but I suspect
>> that this one will not be digested correctly everywhere, even if
>> EUC_JP should be OK to use for the check. How about writing an
>> arbitrary sequence of bytes into a temporary file that gets used for
>> the COPY FROM instead? See for example how we do that with
>> abs_builddir in copy.sql.
>
> It makes sense. How about the attached patch?
>
>
> Thanks,
> --
> kou

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kirill Reshke 2024-12-06 07:22:19 Re: Popcount optimization using SVE for ARM
Previous Message Andrei Lepikhov 2024-12-06 06:48:48 Re: Considering fractional paths in Append node