Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0

From: Andres Freund <andres(at)anarazel(dot)de>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Date: 2015-05-06 20:16:04
Message-ID: 20150506201604.GB12506@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

On 2015-05-06 22:51:43 +0300, Heikki Linnakangas wrote:
> Yeah, I agree that DO NOTHING should not lock the rows. It might make sense
> to have a DO LOCK variant, which locks the rows, although I don't
> immediately see what the use case would be.

If you want to do something more complicated with the row than what you
can do in the UPDATE. To do that right now you either need to do the DO
UPDATE SET ... WHERE false; and refetch the tuple which might not be
easy, or do a DO UPDATE SET pkey = target.pkey which produces
bloat. Consider e.g. you're applying incoming data and in case of
conflict you want to call user defined function deciding which row
should survive.

Greetings,

Andres Freund

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Andreas Karlsson 2015-05-07 01:26:27 Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Previous Message David G. Johnston 2015-05-06 20:03:36 Re: pg_dump: preserving oids in system tables?

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-05-06 20:19:19 Re: Disabling trust/ident authentication configure option
Previous Message Peter Geoghegan 2015-05-06 20:05:16 Re: INSERT ... ON CONFLICT syntax issues