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 1rb7Gp-00DOYB-84 for pgsql-hackers@arkaria.postgresql.org; Fri, 16 Feb 2024 23:05:27 +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 1rb7Gn-005FAf-LP for pgsql-hackers@arkaria.postgresql.org; Fri, 16 Feb 2024 23:05:25 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rb7Gn-005FAX-8V for pgsql-hackers@lists.postgresql.org; Fri, 16 Feb 2024 23:05:25 +0000 Received: from udcm-wwu1.uni-muenster.de ([128.176.118.7]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rb7Gk-007ZxT-Na for pgsql-hackers@lists.postgresql.org; Fri, 16 Feb 2024 23:05:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-muenster.de; i=@uni-muenster.de; q=dns/txt; s=uniout; t=1708124723; x=1739660723; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=PpDa59zaFOdQAKeViVwKrH1nsiHKCvuPyqAkktYxg9k=; b=Yk9v/GbaoK5pDObgQXnFRq38D3QsUKLPuLHH0gYL3pGZEcf056C1caNv 1K9mYN55/2XW9bprYdwKtlFl953wetzPrkuZK3UCScv6rhLj6hWKZ31Bi fKFQWftq7OopmsP7W/+Dd32bnYBIxAkBiEBfEQFKGVcozAmnTawPp/9TZ cWIKm//tavNhcgtHNgDjl6mzjt1EMrBy6799oXnZIlV0UWGN7WGK5s8pf OFSgXZXpflN8twt9oTLSg4nOCCmPpVhmpW3X98tNMHNxyCOuJQDIF6Yhi z42k5g3Ncly1PY7jRMquGwkvWaveKybvQhghasaIMt+jhe6GAo2xpxQ5y Q==; X-CSE-ConnectionGUID: 26stB8HpScqlCiE14hZ5bQ== X-CSE-MsgGUID: OOY/HGtfSzOr2JdZ6A6iJQ== X-IronPort-AV: E=Sophos;i="6.06,165,1705359600"; d="scan'208";a="316364919" Received: from secmail.uni-muenster.de ([128.176.118.4]) by UDCM-RELAY1.UNI-MUENSTER.DE with ESMTP; 17 Feb 2024 00:05:21 +0100 Received: from [192.168.178.27] (dynamic-078-049-110-017.78.49.pool.telefonica.de [78.49.110.17]) by SECMAIL.UNI-MUENSTER.DE (Postfix) with ESMTPSA id D6BCB20ADF19; Sat, 17 Feb 2024 00:05:19 +0100 (CET) Message-ID: <6eac5b45-7f45-4c7a-aae1-e90db8be2e08@uni-muenster.de> Date: Sat, 17 Feb 2024 00:05:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row Content-Language: en-US To: "David G. Johnston" Cc: jian he , Yugo NAGATA , torikoshia , PostgreSQL Hackers References: <20240129172858.ccb6c77c3be95a295e2b2b44@sraoss.co.jp> <04bf425ad1b15a4daefe96c478a5253b@oss.nttdata.com> <20240206191937.72eaf0ccc20cfea37944b422@sraoss.co.jp> <76da9fcc-93c5-4053-872e-12932a95356d@uni-muenster.de> From: Jim Jones In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 16.02.24 21:31, David G. Johnston wrote: > Yes.  In particular not all columns in the table need be specified in > the copy command so while the parsed input data is all nulls the > record itself may not be. Yeah, you have a point there. I guess if users want to avoid it to happen they can rely on NOT NULL constraints. Thanks -- Jim