From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
---|---|
To: | hlinnaka(at)iki(dot)fi, Peter Geoghegan <pg(at)heroku(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Cc: | 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-07 01:26:27 |
Message-ID: | 554ABF43.40708@proxel.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers |
On 05/06/2015 09:51 PM, Heikki Linnakangas wrote:
>> So, yes, DO NOTHING does very little - and that is its appeal.
>> Supporting this behavior does not short change those who actually care
>> about the existing tuple sticking around for the duration of their
>> transaction - they have a way of doing that. If you want to document
>> INSERT IGNORE as being primarily an ETL-orientated thing, that would
>> make sense, but let's not hobble that use case.
>
> 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.
It seems like a very useful feature to me, if you want to upsert
something into a table with a serial column and get the value of the
serial column in a RETURNING clause (but not update any fields if there
is a conflict). Then I am pretty sure I want to lock the row.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | phuongnh2 | 2015-05-07 02:40:00 | Re: Import csv file error with double newline |
Previous Message | Andres Freund | 2015-05-06 20:16:04 | Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0 |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2015-05-07 06:10:03 | Re: Disabling trust/ident authentication configure option |
Previous Message | Heikki Linnakangas | 2015-05-06 22:41:34 | Re: Disabling trust/ident authentication configure option |