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 1rXIZN-009rMM-8f for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Feb 2024 10:20:49 +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 1rXIZM-002os1-G5 for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Feb 2024 10:20:48 +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 1rXIYI-002lrJ-5h for pgsql-hackers@lists.postgresql.org; Tue, 06 Feb 2024 10:19:42 +0000 Received: from ml.sraoss.co.jp ([66.11.59.17]) by makus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rXIYF-005LHl-LE for pgsql-hackers@lists.postgresql.org; Tue, 06 Feb 2024 10:19:40 +0000 Received: from sranhm.sraoss.co.jp (unknown [192.168.174.164]) by osspc26.sraoss.co.jp (Postfix) with ESMTP id 9C2832F000CD; Tue, 6 Feb 2024 19:19:37 +0900 (JST) Received: from yugon-CFSV7-1 (unknown [192.168.176.25]) by sranhm.sraoss.co.jp (Postfix) with SMTP id 7A48E341784; Tue, 6 Feb 2024 19:19:37 +0900 (JST) Date: Tue, 6 Feb 2024 19:19:37 +0900 From: Yugo NAGATA To: jian he Cc: torikoshia , "David G. Johnston" , PostgreSQL Hackers Subject: Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row Message-Id: <20240206191937.72eaf0ccc20cfea37944b422@sraoss.co.jp> In-Reply-To: References: <20240129172858.ccb6c77c3be95a295e2b2b44@sraoss.co.jp> <04bf425ad1b15a4daefe96c478a5253b@oss.nttdata.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 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 Mon, 5 Feb 2024 14:26:46 +0800 jian he wrote: > On Mon, Feb 5, 2024 at 10:29 AM torikoshia wrote: > > > > Hi, > > > > On 2024-02-03 15:22, jian he wrote: > > > The idea of on_error is to tolerate errors, I think. > > > if a column has a not null constraint, let it cannot be used with > > > (on_error 'null') > > > > > + /* > > > + * we can specify on_error 'null', but it can only apply to > > > columns > > > + * don't have not null constraint. > > > + */ > > > + if (att->attnotnull && cstate->opts.on_error == > > > COPY_ON_ERROR_NULL) > > > + ereport(ERROR, > > > + (errcode(ERRCODE_BAD_COPY_FILE_FORMAT), > > > + errmsg("copy on_error 'null' cannot be used with > > > not null constraint column"))); > > > > This means we cannot use ON_ERROR 'null' even when there is one column > > which have NOT NULL constraint, i.e. primary key, right? > > IMHO this is strong constraint and will decrease the opportunity to use > > this feature. > > I don't want to fail in the middle of bulk inserts, > so I thought immediately erroring out would be a great idea. > Let's see what other people think. I also think this restriction is too strong because it is very common that a table has a primary key, unless there is some way to specify columns that can be set to NULL. Even when ON_ERROR is specified, any constraint violation errors cannot be generally ignored, so we cannot elimiate the posibility COPY FROM fails in the middle due to invalid data, anyway. Regards, Yugo Nagata -- Yugo NAGATA