Re: Make COPY format extendable: Extract COPY TO format implementations

On Mon, Oct 13, 2025 at 7:15 PM Sutou Kouhei <kou(at)clear-code(dot)com> wrote:
>
> Hi,
>
> In <CAD21AoBkA=g=PN17r_iieru+vLyLtGZ8WvohgANa2vzsMfMogQ(at)mail(dot)gmail(dot)com>
> "Re: Make COPY format extendable: Extract COPY TO format implementations" on Mon, 13 Oct 2025 14:40:31 -0700,
> Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> > The patch refactors the CopyToStateData so that we can both hide
> > internal-use-only fields from extensions and extension can use its own
> > state data, while not adding extra indirection layers. TBH I'm really
> > not sure we must fully hide internal fields from extensions. Other
> > extendable components seem not to strictly hide internal information
> > from extensions. I'd suggest starting with only the latter point. That
> > is, we merge fields in CopyToStateInternalData to CopyToStateData.
> > What do you think?
>
> OK. Let's follow the existing style. How about the attached
> patch? It merges CopyToStateInternalData to CopyToStateData.
>

The basic idea of this patch makes sense to me.

Andres, I believe that the current idea deals with your concerns about
performance overheads. Particularly, we separate format-specific
fields (c.f. CopyToStateBuiltinData struct in the patch) from the
commonly-used fields (c.f., CopyToStateData struct), but the whole
fields are stored in the contiguous memory. While the patch needs to
be polished much, could you review if the basic idea of this patch
addresses your concern?

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com