RE: ON CONFLICT DO NOTHING on pg_dump - Mailing list pgsql-hackers

From Ideriha, Takeshi
Subject RE: ON CONFLICT DO NOTHING on pg_dump
Date
Msg-id 4E72940DA2BF16479384A86D54D0988A567B39E4@G01JPEXMBKW04
Whole thread Raw
In response to Re: ON CONFLICT DO NOTHING on pg_dump  (Surafel Temesgen <surafel3000@gmail.com>)
List pgsql-hackers
Hi,

>-----Original Message-----
>From: Surafel Temesgen [mailto:surafel3000@gmail.com]
>thank you for the review
>
>    Do you have any plan to support on-conlict-do-update? Supporting this seems
>to me complicated and take much time so I don't mind not implementing this.
>
>
>i agree its complicated and i don't have a plan to implementing it.

Sure.

>thank you for pointing me that i add basic test and it seems to me the rest of the test
>is covered by column_inserts test

Thank you for updating. 
Just one comment for the code.

+       if (dopt.do_nothing && !(dopt.dump_inserts || dopt.column_inserts))
I think you can remove dopt.column_inserts here because at this point dopt.dump_inserts has
already turned true if --column-inserts is specified. 

But I'm just inclined to think that use case of this feature is vague.
Could you specify more concrete use case that is practical for many users?
(It would lead to more attention to this patch.)
For example, is it useful to backup just before making a big change to DB like delete tables?

===
Takeshi

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: WAL prefetch
Next
From: Ashutosh Bapat
Date:
Subject: Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server