From: | Sutou Kouhei <kou(at)clear-code(dot)com> |
---|---|
To: | sawada(dot)mshk(at)gmail(dot)com |
Cc: | michael(at)paquier(dot)xyz, david(dot)g(dot)johnston(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, zhjwpku(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Make COPY format extendable: Extract COPY TO format implementations |
Date: | 2025-06-16 23:50:37 |
Message-ID: | 20250617.085037.540717523379608629.kou@clear-code.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
In <CAD21AoBwxgfkMYxgPWyrLG-r8-ptVKjd=jhncY_QAaVJYhQQdw(at)mail(dot)gmail(dot)com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on Thu, 12 Jun 2025 10:00:12 -0700,
Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>> So, my opinion is to rely on _PG_init(), with a shared ID if you want
>> to expose the method used somewhere for monitoring tools. You could
>> as well implement the simpler set of APIs that allocates IDs local to
>> each backend, like EXPLAIN, then consider later if shared IDs are
>> really needed. The registration APIs don't have to be fixed in time
>> across releases, they can be always improved in steps as required.
>> What matters is ABI compatibility in the same major version once it is
>> released.
>
> +1 to start with a simpler set of APIs.
OK. I'll implement the initial version with this
design. (Allocating IDs local not shared.)
Thanks,
--
kou
From | Date | Subject | |
---|---|---|---|
Next Message | Devulapalli, Raghuveer | 2025-06-16 23:52:55 | RE: Improve CRC32C performance on SSE4.2 |
Previous Message | Peter Geoghegan | 2025-06-16 23:47:01 | Re: Returning nbtree posting list TIDs in DESC order during backwards scans |