Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rE059-003qlL-GU for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Dec 2023 04:45:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rE055-00FLlR-Ne for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Dec 2023 04:45:47 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rE054-00FLlJ-K8 for pgsql-hackers@lists.postgresql.org; Fri, 15 Dec 2023 04:45:47 +0000 Received: from mail.clear-code.com ([2401:2500:102:3039:153:126:206:245]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rE04z-00AT8j-Vl for pgsql-hackers@postgresql.org; Fri, 15 Dec 2023 04:45:44 +0000 Received: from localhost (unknown [IPv6:2404:7a80:89c1:1200:1653:202c:ea56:2daf]) by mail.clear-code.com (Postfix) with ESMTPSA id 853236FE597; Fri, 15 Dec 2023 13:45:33 +0900 (JST) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.clear-code.com 853236FE597 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=clear-code.com; s=default; t=1702615533; bh=22787C07jMKVixjCGuzPSobqePNPkh0TItxpVE1WVtw=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=fMQFFerUVDcY0JZQHpQEhPcxtrfJhHaQqZrzoAZZpAz+nN1puaeK1FZiEHxj9r1EW JWBlhSqVrH0EdQkuYmNp8g5wFFdI8PL61VqlFA3hwLYHt7ezhg2haMBdLhYxV6Drtp FniBM45FtJjgEU7QWwuLotn3vZkUq4eMaxnWN1eI= Date: Fri, 15 Dec 2023 13:45:31 +0900 (JST) Message-Id: <20231215.134531.262492849300453689.kou@clear-code.com> To: zhjwpku@gmail.com Cc: sawada.mshk@gmail.com, michael@paquier.xyz, andrew@dunslane.net, nathandbossart@gmail.com, pgsql-hackers@postgresql.org Subject: Re: Make COPY format extendable: Extract COPY TO format implementations From: Sutou Kouhei In-Reply-To: References: <20231215.095305.1361997086905276509.kou@clear-code.com> X-Mailer: Mew version 6.8 on Emacs 29.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 853236FE597 X-Rspamd-Server: mail.clear-code.com X-Spamd-Result: default: False [2.90 / 999.00]; SUSPICIOUS_RECIPS(1.50)[]; MID_CONTAINS_FROM(1.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2518, ipnet:2404:7a80::/29, country:JP]; RCVD_COUNT_ZERO(0.00)[0]; FREEMAIL_TO(0.00)[gmail.com]; TAGGED_RCPT(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; URIBL_BLOCKED(0.00)[localhost:helo]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,paquier.xyz,dunslane.net,postgresql.org]; RCPT_COUNT_FIVE(0.00)[6]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; SURBL_MULTI_FAIL(0.00)[localhost:server fail] X-Rspamd-Action: no action List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, In "Re: Make COPY format extendable: Extract COPY TO format implementations" on Fri, 15 Dec 2023 11:27:30 +0800, Junwang Zhao 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