Date: Wed, 05 Feb 2025 16:31:56 +0900 (JST)
Message-Id: <20250205.163156.1535621111236702609.kou@clear-code.com>
To: v.popolitov@postgrespro.ru
Cc: sawada.mshk@gmail.com, zhjwpku@gmail.com, michael@paquier.xyz,
 pgsql-hackers@postgresql.org
Subject: Re: Make COPY format extendable: Extract COPY TO format
 implementations
From: Sutou Kouhei <kou@clear-code.com>
In-Reply-To: <eb59c12bb36207c65f23719f255eb69b@postgrespro.ru>
References: <d838025aceeb19c9ff1db702fa55cabf@postgrespro.ru>
	<20250204.152927.1922290693174479861.kou@clear-code.com>
	<eb59c12bb36207c65f23719f255eb69b@postgrespro.ru>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/20250205.163156.1535621111236702609.kou%40clear-code.com>
Precedence: bulk

Hi,

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