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 <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1rTEwr-001LiF-Pt
	for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Jan 2024 05:40:18 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.94.2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1rTEwq-009drP-PL
	for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Jan 2024 05:40:16 +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 <nagata@sraoss.co.jp>)
	id 1rTEwq-009dr1-Ft
	for pgsql-hackers@lists.postgresql.org; Fri, 26 Jan 2024 05:40:16 +0000
Received: from ml.sraoss.co.jp ([66.11.59.17])
	by makus.postgresql.org with esmtp (Exim 4.94.2)
	(envelope-from <nagata@sraoss.co.jp>)
	id 1rTEwn-003Q7Q-9Y
	for pgsql-hackers@postgresql.org; Fri, 26 Jan 2024 05:40:15 +0000
Received: from sranhm.sraoss.co.jp (unknown [192.168.174.164])
	by osspc26.sraoss.co.jp (Postfix) with ESMTP id 8A5B02F000BA;
	Fri, 26 Jan 2024 14:40:11 +0900 (JST)
Received: from yugon-CFSV7-1 (unknown [192.168.176.17])
	by sranhm.sraoss.co.jp (Postfix) with SMTP id 6B93A341777;
	Fri, 26 Jan 2024 14:40:11 +0900 (JST)
Date: Fri, 26 Jan 2024 14:40:11 +0900
From: Yugo NAGATA <nagata@sraoss.co.jp>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Small fix on COPY ON_ERROR document
Message-Id: <20240126144011.8fc3e1ea1d450fd0fe2ad2fa@sraoss.co.jp>
In-Reply-To: 
 <CAD21AoBAAxPdEdDJTwJRQbiQ-+xhfPDcfcPPSddpzTsO9xMLzw@mail.gmail.com>
References: <20240126112829.d420b28859fbe84379fdb7ad@sraoss.co.jp>
	<CAD21AoBAAxPdEdDJTwJRQbiQ-+xhfPDcfcPPSddpzTsO9xMLzw@mail.gmail.com>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/mixed;
 boundary="Multipart=_Fri__26_Jan_2024_14_40_11_+0900_zq36Uv2dKyiFwlqE"
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/20240126144011.8fc3e1ea1d450fd0fe2ad2fa%40sraoss.co.jp>
Precedence: bulk

This is a multi-part message in MIME format.

--Multipart=_Fri__26_Jan_2024_14_40_11_+0900_zq36Uv2dKyiFwlqE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Fri, 26 Jan 2024 13:59:09 +0900
Masahiko Sawada <sawada.mshk@gmail.com> wrote:

> On Fri, Jan 26, 2024 at 11:28 AM Yugo NAGATA <nagata@sraoss.co.jp> wrote:
> >
> > Hi,
> >
> > I found that the documentation of COPY ON_ERROR said
> > COPY stops operation at the first error when
> > "ON_ERROR is not specified.", but it also stop when
> > ON_ERROR is specified to the default value, "stop".
> >
> > I attached a very small patch to fix this just for
> > making the description more accurate.
> 
> Thank you for the patch!
> 
> +1 to fix it.
> 
> -    <literal>ON_ERROR</literal> is not specified. This
> -    should not lead to problems in the event of a <command>COPY
> +    <literal>ON_ERROR</literal> is not specified or <literal>stop</literal>.
> +    This should not lead to problems in the event of a <command>COPY
> 
> How about the followings for consistency with the description of the
> ON_ERROR option?
> 
> COPY stops operation at the first error if the stop value is specified
> to the ON_ERROR option. This should not lead to ...

Thank you for you review. However, after posting the previous patch, 
I noticed that I overlooked ON_ERROR works only for errors due to data
type incompatibility (that is mentioned as "malformed data" in the 
ON_ERROR description, though). 

So, how about rewriting this like:

 COPY stops operation at the first error unless the error is due to data
 type incompatibility and a value other than stop is specified to the
 ON_ERROR option.

I attached the updated patch.

Regards,
Yugo Nagata

> 
> Regards,
> 
> -- 
> Masahiko Sawada
> Amazon Web Services: https://aws.amazon.com


-- 
Yugo NAGATA <nagata@sraoss.co.jp>

--Multipart=_Fri__26_Jan_2024_14_40_11_+0900_zq36Uv2dKyiFwlqE
Content-Type: text/x-diff;
 name="v2_small_fix_on_copy_doc.patch"
Content-Disposition: attachment;
 filename="v2_small_fix_on_copy_doc.patch"
Content-Transfer-Encoding: 7bit

diff --git a/doc/src/sgml/ref/copy.sgml b/doc/src/sgml/ref/copy.sgml
index 21a5c4a052..3676bf0e87 100644
--- a/doc/src/sgml/ref/copy.sgml
+++ b/doc/src/sgml/ref/copy.sgml
@@ -576,9 +576,10 @@ COPY <replaceable class="parameter">count</replaceable>
    </para>
 
    <para>
-    <command>COPY</command> stops operation at the first error when
-    <literal>ON_ERROR</literal> is not specified. This
-    should not lead to problems in the event of a <command>COPY
+    <command>COPY</command> stops operation at the first error unless the error
+    is due to data type incompatibility and a value other than
+    <literal>stop</literal> is specified to the <literal>ON_ERROR</literal> option.
+    This should not lead to problems in the event of a <command>COPY
     TO</command>, but the target table will already have received
     earlier rows in a <command>COPY FROM</command>. These rows will not
     be visible or accessible, but they still occupy disk space. This might

--Multipart=_Fri__26_Jan_2024_14_40_11_+0900_zq36Uv2dKyiFwlqE--