From: Nico Williams <nico(at)cryptonector(dot)com>
To: "Ideriha, Takeshi" <ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Surafel Temesgen <surafel3000(at)gmail(dot)com>
Subject: Re: ON CONFLICT DO NOTHING on pg_dump
Date: 2018-06-18 15:28:51
Message-ID: 20180618152849.GA4200@localhost
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Fri, Jun 15, 2018 at 02:20:21AM +0000, Ideriha, Takeshi wrote:
> >From: Nico Williams [mailto:nico(at)cryptonector(dot)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.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-06-18 15:57:19 Re: Server crashed with TRAP: FailedAssertion("!(parallel_workers > 0)" when partitionwise_aggregate true.
Previous Message Jesper Pedersen 2018-06-18 15:25:39 Index Skip Scan