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 1tsHPn-0000ii-M1 for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Mar 2025 08:26:11 +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 1tsHPm-00HIIb-2V for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Mar 2025 08:26:10 +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 1tsHPl-00HIE1-LP for pgsql-hackers@lists.postgresql.org; Wed, 12 Mar 2025 08:26:09 +0000 Received: from udcm-wwu1.uni-muenster.de ([128.176.118.7]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tsHPe-002Nsh-2n for pgsql-hackers@lists.postgresql.org; Wed, 12 Mar 2025 08:26:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-muenster.de; i=@uni-muenster.de; q=dns/txt; s=uniout; t=1741767963; x=1773303963; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=3c0zXcPEgptLjHAWQfznZgiPps0UjEv9UfsGIQGViIc=; b=hCTPDTyaR+cfqRw75EWPeNhPw1VZJvc4YXPZSY74Ld3t+xCyiBmPj/Jv no1lqKljUUJKUckHyLAKYl0Dz615rw2PDbOyxDY2iJsRVdteZzHhd5PCf UEQzOiEiTnmQwg7HhnuHUQzBdNJ1jvzpaEK9rP975o+juEYfl18ptgGrE 7vwXmXiSR4NUz96XnuNs5Rc71lnWwqCvg5oAfTYwPlg0abPqdTNWS4Q67 VCMfvS2OfD2V8zcS9RZq+JRP02CUQpnW0L1VcH8wZkO+SqWW0uNOp23+h UH8tyehItOoUiXhLdCxYmVSALURC187tQ3QN5sVX05OULiBAT3+EgAnei Q==; X-CSE-ConnectionGUID: XVpchn+DS16d8XsYmYi1YA== X-CSE-MsgGUID: n1343wT7RbODZU13MxoA2Q== X-IronPort-AV: E=Sophos;i="6.14,241,1736809200"; d="scan'208";a="358981550" Received: from secmail.uni-muenster.de ([128.176.118.4]) by UDCM-RELAY1.UNI-MUENSTER.DE with ESMTP; 12 Mar 2025 09:26:01 +0100 Received: from [192.168.178.27] (dynamic-080-171-219-223.80.171.pool.telefonica.de [80.171.219.223]) by SECMAIL.UNI-MUENSTER.DE (Postfix) with ESMTPSA id 3F40A20ADF03; Wed, 12 Mar 2025 09:25:59 +0100 (CET) Message-ID: Date: Wed, 12 Mar 2025 09:25:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row To: jian he Cc: Kirill Reshke , Fujii Masao , "David G. Johnston" , Yugo NAGATA , torikoshia , PostgreSQL Hackers References: <90dc6e9d-9348-485a-b27c-7b1637f06c2e@uni-muenster.de> Content-Language: en-US, de-DE From: Jim Jones In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 12.03.25 09:00, jian he wrote: >> 1) WARNING might be a better fit than NOTICE here. >> > but NOTICE, on_errror set_to_null is aligned with on_errror ignore. > >> I would still leave the extra messages from "log_verbosity verbose" as >> NOTICE though. What do you think? >> >> ==== > When LOG_VERBOSITY option is set to verbose, > for ignore option, a NOTICE message containing the line of the input > file and the column name > whose input conversion has failed is emitted for each discarded row; > for set_to_null option, a NOTICE message containing the line of the > input file and the column name > where value was replaced with NULL for each input conversion failure. > > see the above desciption, > on_errror set_to_null is aligned with on_errror ignore. > it's just on_errror ignore is per row, on_errror set_to_null is per > column/field. > so NOTICE is aligned with other on_error option. I considered using a WARNING due to the severity of the issue - the failure to import data - but either NOTICE or WARNING works for me. >> 2) Inconsistent terminology. Invalid values in "on_error set_to_null" >> mode are names as "erroneous", but as "invalid" in "on_error stop" mode. >> I don't want to get into the semantics of erroneous or invalid, but >> sticking to one terminology would IMHO look better. >> > I am open to changing it. > what do you think "invalid values in %llu row was replaced with null"? LGTM: "invalid values in %llu rows were replaced with null" Thanks for the patch! Best, Jim