Hi, In <eb59c12bb36207c65f23719f255eb...@postgrespro.ru> "Re: Make COPY format extendable: Extract COPY TO format implementations" on Tue, 04 Feb 2025 17:46:10 +0700, Vladlen Popolitov <v.popoli...@postgrespro.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
