Date: Wed, 6 May 2015 22:16:04 +0200
From: Andres Freund <andres@anarazel.de>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Peter Geoghegan <pg@heroku.com>, Jeff Janes <jeff.janes@gmail.com>,
 Stephen Frost <sfrost@snowman.net>,
 Dean Rasheed <dean.a.rasheed@gmail.com>, Bruce Momjian <bruce@momjian.us>,
 Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Message-ID: <20150506201604.GB12506@alap3.anarazel.de>
References: 
 <CAM3SWZTGE0z5_E8wRi9wt3qgOiMpSwtwr5uDcZDGhRZ1_pz6vg@mail.gmail.com>
 <20150505154030.GI9855@alap3.anarazel.de>
 <CAM3SWZTU8FgwoMb-vKZv_LsQb75nH=NP9+dCdTj9S4GScMtk=A@mail.gmail.com>
 <20150506152007.GN9855@alap3.anarazel.de>
 <CAM3SWZS2aWL56NnMcgcGJcUETMBavL9w_-miyAV1q2PLG6OBNA@mail.gmail.com>
 <554A70CF.8090608@iki.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <554A70CF.8090608@iki.fi>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers