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

From Nico Williams
Subject Re: ON CONFLICT DO NOTHING on pg_dump
Date
Msg-id 20180618152849.GA4200@localhost
Whole thread Raw
In response to RE: ON CONFLICT DO NOTHING on pg_dump  ("Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com>)
Responses RE: ON CONFLICT DO NOTHING on pg_dump
List pgsql-hackers
On Fri, Jun 15, 2018 at 02:20:21AM +0000, Ideriha, Takeshi wrote:
> >From: Nico Williams [mailto:nico@cryptonector.com]
> >On Tue, Jun 12, 2018 at 09:05:23AM +0000, Ideriha, Takeshi wrote:
> >> Only the difference of data can be restored.
> >
> >But that's additive-only.  Only missing rows are restored this way, and differences are
> >not addressed.
> >
> >If you want restore to restore data properly and concurrently (as opposed to renaming
> >a new database into place or whatever) then you'd want a) MERGE, b) dump to
> >generate MERGE statements.  A concurrent data restore operation would be rather
> >neat.
> 
> I agree with you though supporting MERGE or ON-CONFLICT-DO-UPDATE seems hard work.
> Only ON-CONCLICT-DO-NOTHING use case may be narrow.

Is it narrow, or is it just easy enough to add quickly?

And by the way, you don't need MERGE.  You can just generate INSERT/
UPDATE/DELETE statements -- MERGE is mainly an optimization on that, and
could wait until PG has a MERGE.

Nico
-- 


pgsql-hackers by date:

Previous
From: Jesper Pedersen
Date:
Subject: Index Skip Scan
Next
From: Andres Freund
Date:
Subject: Re: Server crashed with TRAP: FailedAssertion("!(parallel_workers >0)" when partitionwise_aggregate true.