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

From Surafel Temesgen
Subject Re: Conflict handling for COPY FROM
Date
Msg-id CALAY4q-4+p3j7dD-a1rPjCw5u9k8XCXxSu6dJwLe3iCRiQR6Pw@mail.gmail.com
Whole thread Raw
In response to Re: Conflict handling for COPY FROM  (Andres Freund <andres@anarazel.de>)
Responses Re: Conflict handling for COPY FROM
Re: Conflict handling for COPY FROM
List pgsql-hackers

On Wed, Feb 20, 2019 at 7:04 PM Andres Freund <andres@anarazel.de> wrote:


On February 20, 2019 6:05:53 AM PST, Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:
>
>On 2/20/19 8:01 AM, Surafel Temesgen wrote:
>>
>>
>> On Tue, Feb 19, 2019 at 3:47 PM Andres Freund <andres@anarazel.de
>> <mailto:andres@anarazel.de>> wrote:
>>
>>
>>
>>     Err, what? Again, that requires super user permissions (in
>>     contrast to copy from/to stdin/out). Backends run as the user
>>     postgres runs under
>>
>>
>>  
>> okay i see it now and modified the patch similarly 
>>
>>
>
>
>Why log to a file at all? We do have, you know, a database handy, where
>we might more usefully log errors. You could usefully log the offending
>row as an array of text, possibly.

Or even just return it as a row. CopyBoth is relatively widely supported these days.


hello,
i think generating warning about it also sufficiently meet its propose of
notifying user about skipped record with existing logging facility
and we use it for similar propose in other place too. The different
i see is the number of warning that can be generated

In addition to the above change in the attached patch i also change
the syntax to ERROR LIMIT because it is no longer only skip
unique and exclusion constrain violation
regards
Surafel 
 
Attachment

pgsql-hackers by date:

Previous
From: Yugo Nagata
Date:
Subject: Re: Implementing Incremental View Maintenance
Next
From: Amit Kapila
Date:
Subject: Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions