Re: Small fix on COPY ON_ERROR document

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Small fix on COPY ON_ERROR document
Date: 2024-01-26 07:00:57
Message-ID: CAKFQuwYSR61-wqoQKRbmWs7cqHTQOpJRz8o8Jo4H_ddFSRMs-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, January 25, 2024, Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> wrote:

>
> Maybe, we can separate the sentese to two, for example:
>
> COPY stops operation at the first error. (The exception is if the error
> is due to data type incompatibility and a value other than stop is
> specified
> to the ON_ERROR option.)
>

I’d lean more toward saying:

Copy from can be instructed to ignore errors that arise from casting input
data to the data types of the target columns by setting the on_error option
to ignore. Skipping the entire input row in the process.

The last part is because another way to ignore would be to set null values
for those columns.

That a command stops on an error is the assumed behavior throughout the
system, writing “copy stops operation at the first error.” just seems
really unnecessary.

I will need to make this tweak and probably a couple others to my own
suggestions in 12 hours or so.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2024-01-26 07:04:47 Re: Remove unused fields in ReorderBufferTupleBuf
Previous Message David Rowley 2024-01-26 06:54:16 Delay Memoize hashtable build until executor run