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 1sWGDp-00E8EC-Ty
	for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Jul 2024 14:10:33 +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 1sWGDm-00DyjQ-Ad
	for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Jul 2024 14:10:30 +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 <torikoshia@oss.nttdata.com>)
	id 1sWGDm-00DyjI-17
	for pgsql-hackers@lists.postgresql.org; Tue, 23 Jul 2024 14:10:30 +0000
Received: from oss.nttdata.com ([49.212.34.109])
	by makus.postgresql.org with esmtps  (TLS1.2) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <torikoshia@oss.nttdata.com>)
	id 1sWGDi-0012vT-VK
	for pgsql-hackers@lists.postgresql.org; Tue, 23 Jul 2024 14:10:28 +0000
Received: from oss.nttdata.com (localhost [127.0.0.1])
	by oss.nttdata.com (Postfix) with ESMTPA id 961ED619B9;
	Tue, 23 Jul 2024 23:10:24 +0900 (JST)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.103.11 at oss.nttdata.com
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 23 Jul 2024 23:10:24 +0900
From: torikoshia <torikoshia@oss.nttdata.com>
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, zhjwpku@gmail.com,
 pgsql-hackers@lists.postgresql.org
Subject: Re: Add new COPY option REJECT_LIMIT
In-Reply-To: 
 <CALdSSPjgKyFRnqPV2BfUDDb1xx4CPO4sLZKbEKFLf5FOMBkpQQ@mail.gmail.com>
References: <63f99327aa6b404cc951217fa3e61fe4@oss.nttdata.com>
 <fab7018f-6e00-4be4-bd1e-4a013096f6c9@oss.nttdata.com>
 <de0551d0f9d9e9072e324e51ed5c426d@oss.nttdata.com>
 <6e3dcdc6-8e18-4716-a23b-3bee316aeaa7@oss.nttdata.com>
 <979c6d306343f3d665d14eab2cd1b7bc@oss.nttdata.com>
 <920a29a36032befbeb355cbdfbbe0f63@oss.nttdata.com>
 <a873643c-e7d1-456c-b16b-6162ab698036@oss.nttdata.com>
 <54bea7dd-94b1-41f1-a4e9-c5c53cc82ce7@oss.nttdata.com>
 <f9feda0ecd4e2e09620a6f9ca8f4aac1@oss.nttdata.com>
 <CALdSSPjgKyFRnqPV2BfUDDb1xx4CPO4sLZKbEKFLf5FOMBkpQQ@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <e2849c17dabaac61a6a628a2cc60f4ab@oss.nttdata.com>
X-Sender: torikoshia@oss.nttdata.com
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/e2849c17dabaac61a6a628a2cc60f4ab%40oss.nttdata.com>
Precedence: bulk

On 2024-07-23 02:06, Kirill Reshke wrote:

Thanks for your review.

> Few comments:
> 
>> +      When a positive integer value is specified, 
>> <command>COPY</command> limits
>> +      the maximum tolerable number of errors while converting a 
>> column's input
>> +      value into its data type.
> 
> If nothing is specified, then the maximum tolerable number of errors
> is one, right? Should we state  this explicitly in the documentation?

REJECT_LIMIT now can be used wonly when on_error=ignore, I think the 
default(when only on_error=ignore is specified) is unlimited.
Anyway, I'm going to add a description about the default.

>> +COPY x from stdin with (on_error ignore, reject_limit 0);
> How about a test where reject_limit is a string, but not
> (case-intensively) 'infinity'?

Considering the discussion in[1], I'm now going to remove 'infinity'.

>> + CopyRejectLimits reject_limits; /* thresholds of reject_limit */
> 
> Why are there multiple thresholds? Can we have only one?

This is because I thought it'd be more convenient to support both the 
number and the ratio of error, but I'm also beginning to think that it 
might be better to support only the number of cases, as discussed in 
[1].

[1]https://www.postgresql.org/message-id/5f807fcf3a36df7ba41464ab40b5c37d%40oss.nttdata.com

-- 
Regards,

--
Atsushi Torikoshi
NTT DATA Group Corporation