Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row
Date: 2024-01-29 00:19:47
Message-ID: CAKFQuwaTbpvRtvmewXjL-V08CLy5=HSL6ehccAZgSGVkcH-WXg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jan 28, 2024 at 4:51 PM jian he <jian(dot)universality(at)gmail(dot)com> wrote:

> On Fri, Jan 26, 2024 at 11:09 PM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> >
> > Hi,
> >
> > The option choice of "ignore" in the COPY ON_ERROR clause seems overly
> generic. There would seem to be two relevant ways to ignore bad column
> input data - drop the entire row or just set the column value to null. I
> can see us wanting to provide the set to null option and in any case having
> the option name be explicit that it ignores the row seems like a good idea.
>
> two issue I found out while playing around with it;
> create table x1(a int not null, b int not null );
>
> another issue:
> COPY x1 from stdin (on_error null);
>
> when we already have `not null` top level constraint for table x1.
> Do we need an error immediately?
> "on_error null" seems to conflict with `not null` constraint (assume
> refers to the same column).
> it may fail while doing bulk inserts while on_error is set to null
> because of violating a not null constraint.
>

You should not error immediately since whether or not there is a problem is
table and data dependent. I would not check for the case of all columns
being defined not null and just let the mismatch happen.

That said, maybe with this being a string we can accept something like:
'null, ignore'

And so if attempting to place any one null fails, assuming we can make that
a soft error too, we would then ignore the entire row.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2024-01-29 01:04:18 Re: Documentation to upgrade logical replication cluster
Previous Message Michael Paquier 2024-01-29 00:09:48 Re: Use of backup_label not noted in log