public inbox for [email protected]  

help / color / mirror / Atom feed

From: Sutou Kouhei <[email protected]>
To: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: Make COPY format extendable: Extract COPY TO format implementations
Date: Wed, 05 Feb 2025 16:31:56 +0900 (JST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>

Hi,

In <[email protected]>
  "Re: Make COPY format extendable: Extract COPY TO format implementations" on Tue, 04 Feb 2025 17:46:10 +0700,
  Vladlen Popolitov <[email protected]> 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

view thread (2+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Make COPY format extendable: Extract COPY TO format implementations
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox