From: | Sutou Kouhei <kou(at)clear-code(dot)com> |
---|---|
To: | zhjwpku(at)gmail(dot)com |
Cc: | sawada(dot)mshk(at)gmail(dot)com, michael(at)paquier(dot)xyz, andrew(at)dunslane(dot)net, nathandbossart(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Make COPY format extendable: Extract COPY TO format implementations |
Date: | 2024-01-15 06:23:50 |
Message-ID: | 20240115.152350.1128880926282754664.kou@clear-code.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
In <CAEG8a3J02NzGBxG1rP9C4u7qRLOqUjSOdy3q5_5v__fydS3XcA(at)mail(dot)gmail(dot)com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on Fri, 12 Jan 2024 14:40:41 +0800,
Junwang Zhao <zhjwpku(at)gmail(dot)com> wrote:
>> Could you clarify what should we discuss? We should require
>> that COPY TO/FROM handlers should use PostgreSQL's memory
>> context for all internal memory allocations?
>
> Yes, handlers should use PostgreSQL's memory context, and I think
> creating other memory context under CopyToStateData.copycontext
> should be suggested for handler creators, so I proposed exporting
> CopyToStateData to public header.
I see.
We can provide a getter for CopyToStateData::copycontext if
we don't want to export CopyToStateData. Note that I don't
have a strong opinion whether we should export
CopyToStateData or not.
Thanks,
--
kou
From | Date | Subject | |
---|---|---|---|
Next Message | Kirk Wolak | 2024-01-15 06:24:31 | Oom on temp (un-analyzed table caused by JIT) V16.1 |
Previous Message | vignesh C | 2024-01-15 06:05:25 | Commitfest 2024-01 second week update |