Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
От | Peter Geoghegan |
---|---|
Тема | Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0 |
Дата | |
Msg-id | CAM3SWZS2aWL56NnMcgcGJcUETMBavL9w_-miyAV1q2PLG6OBNA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
|
Список | pgsql-hackers |
On Wed, May 6, 2015 at 8:20 AM, Andres Freund <andres@anarazel.de> wrote: > On 2015-05-05 15:00:56 -0700, Peter Geoghegan wrote: >> Locking the row is not "nothing", though. If you want to lock the row, >> use an UPSERT with a tautologically false WHERE clause (like "WHERE >> false"). > > That's not the same. For one it "breaks" RETURNING which is a death > knell, for another it's not exactly obvious. DO NOTHING already doesn't project non-inserted tuples, in a way that fits with the way we won't do that when a before trigger returns NULL. So I don't know what you mean about RETURNING behavior. It may not be all that obvious, but then the requirement that you mention isn't either. I really strongly feel that DO NOTHING should do nothing. For the pgloader use-case, which is what I have in mind with that variant, that could literally make the difference between dirtying an enormous number of buffers and dirtying only a few. This will *frequently* be the case. And it's not as if the idea of an INSERT IGNORE is new or in any way novel. As I mentioned, many systems have a comparable command. 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. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: