pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Sutou Kouhei <kou@clear-code.com>
To: zhjwpku@gmail.com
Cc: sawada.mshk@gmail.com
Cc: michael@paquier.xyz
Cc: andrew@dunslane.net
Cc: nathandbossart@gmail.com
Cc: pgsql-hackers@postgresql.org
Subject: Re: Make COPY format extendable: Extract COPY TO format implementations
Date: Fri, 15 Dec 2023 13:45:31 +0900 (JST)
Message-ID: <20231215.134531.262492849300453689.kou@clear-code.com> (raw)
In-Reply-To: <CAEG8a3JuShA6g19Nt_Ejk15BrNA6PmeCbK7p81izZi71muGq3g@mail.gmail.com>
References: <CAD21AoCZv3cVU+NxR2s9J_dWvjrS350GFFr2vMgCH8wWxQ5hTQ@mail.gmail.com>
	<20231215.095305.1361997086905276509.kou@clear-code.com>
	<CAEG8a3JuShA6g19Nt_Ejk15BrNA6PmeCbK7p81izZi71muGq3g@mail.gmail.com>

Hi,

In <CAEG8a3JuShA6g19Nt_Ejk15BrNA6PmeCbK7p81izZi71muGq3g@mail.gmail.com>
  "Re: Make COPY format extendable: Extract COPY TO format implementations" on Fri, 15 Dec 2023 11:27:30 +0800,
  Junwang Zhao <zhjwpku@gmail.com> wrote:

>> > Adding a prefix or suffix would be one option but to give extensions
>> > more flexibility, another option would be to support format = 'custom'
>> > and add the "handler" option to specify a copy handler function name
>> > to call. For example, COPY ... FROM ... WITH (FORMAT = 'custom',
>> > HANDLER = 'arrow_copy_handler').
>>
> I like the prefix/suffix idea, easy to implement. *custom* is not a FORMAT,
> and user has to know the name of the specific handler names, not
> intuitive.

Ah! I misunderstood this idea. "custom" is the special
format to use "HANDLER". I thought that we can use it like

   (FORMAT = 'arrow', HANDLER = 'arrow_copy_handler_impl1')

and

   (FORMAT = 'arrow', HANDLER = 'arrow_copy_handler_impl2')

.

>> Interesting. If we use this option, users can choose an COPY
>> FORMAT implementation they like from multiple
>> implementations. For example, a developer may implement a
>> COPY FROM FORMAT = 'json' handler with PostgreSQL's JSON
>> related API and another developer may implement a handler
>> with simdjson[1] which is a fast JSON parser. Users can
>> choose whichever they like.
> Not sure about this, why not move Json copy handler to contrib
> as an example for others, any extensions share the same format
> function name and just install one? No bound would implement
> another CSV or TEXT copy handler IMHO.

I should have used a different format not JSON as an example
for easy to understand. I just wanted to say that extension
developers can implement another implementation without
conflicting another implementation.


Thanks,
-- 
kou





view thread (340+ messages)  latest in thread

Message-ID: <20231215.134531.262492849300453689.kou@clear-code.com>
Permalink:  ../20231215.134531.262492849300453689.kou@clear-code.com/
Also on:    postgresql.org/message-id/20231215.134531.262492849300453689.kou@clear-code.com

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: pgsql-hackers@postgresql.org
  Cc: kou@clear-code.com, zhjwpku@gmail.com, sawada.mshk@gmail.com, michael@paquier.xyz, andrew@dunslane.net, nathandbossart@gmail.com
  Subject: Re: Make COPY format extendable: Extract COPY TO format implementations
  In-Reply-To: <20231215.134531.262492849300453689.kou@clear-code.com>

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

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