Re: ON CONFLICT DO NOTHING on pg_dump

Поиск
Список
Период
Сортировка
От Nico Williams
Тема Re: ON CONFLICT DO NOTHING on pg_dump
Дата
Msg-id 20180618152849.GA4200@localhost
обсуждение исходный текст
Ответ на RE: ON CONFLICT DO NOTHING on pg_dump  ("Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com>)
Ответы RE: ON CONFLICT DO NOTHING on pg_dump  ("Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com>)
Список 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 по дате отправления:

Предыдущее
От: Jesper Pedersen
Дата:
Сообщение: Index Skip Scan
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Server crashed with TRAP: FailedAssertion("!(parallel_workers >0)" when partitionwise_aggregate true.