Re: Conflict handling for COPY FROM - Mailing list pgsql-hackers

From Surafel Temesgen
Subject Re: Conflict handling for COPY FROM
Date
Msg-id CALAY4q9TZ1cZc04A0_KOhBKAZe3jWeqEXSqJgVtQymD8v9u1BQ@mail.gmail.com
Whole thread Raw
In response to Re: Conflict handling for COPY FROM  (Alexey Kondratov <a.kondratov@postgrespro.ru>)
Responses RE: Conflict handling for COPY FROM  ("asaba.takanori@fujitsu.com" <asaba.takanori@fujitsu.com>)
List pgsql-hackers


On Thu, Nov 21, 2019 at 4:22 PM Alexey Kondratov <a.kondratov@postgrespro.ru> wrote:

Now the whole patch works exactly as expected for me and I cannot find
any new technical flaws. However, the doc is rather vague, especially
these places:

+      specifying it to -1 returns all error record.

Actually, we return only rows with constraint violation, but malformed
rows are ignored with warning. I guess that we simply cannot return
malformed rows back to the caller in the same way as with constraint
violation, since we cannot figure out (in general) which column
corresponds to which type if there are extra or missing columns.

+      and same record formatting error is ignored.

I can get it, but it definitely should be reworded.

What about something like this?

+   <varlistentry>
+ <term><literal>ERROR_LIMIT</literal></term>
+    <listitem>
+     <para>
+      Enables ignoring of errored out rows up to <replaceable
+      class="parameter">limit_number</replaceable>. If <replaceable
+      class="parameter">limit_number</replaceable> is set
+      to -1, then all errors will be ignored.
+     </para>
+
+     <para>
+      Currently, only unique or exclusion constraint violation
+      and rows formatting errors are ignored. Malformed
+      rows will rise warnings, while constraint violating rows
+      will be returned back to the caller.
+     </para>
+
+    </listitem>
+   </varlistentry>



It is better so changed

regards
Surafel
Attachment

pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: Safeguards against incorrect fd flags for fsync()
Next
From: Michael Paquier
Date:
Subject: Re: Problem during Windows service start