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

Hi,

In <eb59c12bb36207c65f23719f255eb69b(at)postgrespro(dot)ru>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on Tue, 04 Feb 2025 17:46:10 +0700,
Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)ru> wrote:

> I think, in case of USING PostgreSQL kernel will call corresponding
> handler,
> and it looks secure - the same as for table and index methods
> handlers.

We use similar approach that is used by table sampling
method. We can use a new table sampling method by just
adding a "method_name(internal) RETURNS tsm_handler"
function. Is it not secure too?

> If you add extensibility, than every handler will be the
> extension, that can handle one or more formats.

Hmm. It may be a needless extensibility. Is it useful? I
feel that it increases complexity when we implement a custom
format handler. We can just implement one handler per custom
format. If we want to share implementation details in
multiple handlers, we can just share internal C
functions.

If we require one handler per custom format, it'll simpler
than one handler for multiple custom formats.

>>> it assumes some SetOptions interface, that defines
>>> an options structure according to the new method requirements.
>> Sorry. I couldn't find the SetOptions interface in source
>> code. I found only AT_SetOptions. Did you mean it by "some
>> SetOptions interface"?
> Yes.
>> I'm familiar with only access method. It has
>> IndexAmRoutine::amoptions. Is it a SetOptions interface
>> example?
> Yes. I think, it would be compatible with other modules
> of source code and could use the same code base to process
> options of COPY TO/FROM

Thanks. I thought that there is a common interface pattern
for SetOptions. But it seems that it's a feature that is
implemented in many extension points.

If we implement custom options support eventually, does it
satisfy the "SetOptions interface"?

Thanks,
--
kou