Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0
От | Heikki Linnakangas |
---|---|
Тема | Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0 |
Дата | |
Msg-id | 55395142.9080008@iki.fi обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0
Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0 |
Список | pgsql-hackers |
On 04/23/2015 10:53 PM, Andres Freund wrote: > On 2015-04-23 12:45:59 -0700, Peter Geoghegan wrote: >> On Thu, Apr 23, 2015 at 12:55 AM, Andres Freund <andres@anarazel.de> wrote: >>> I think you misread my statement: I'm saying we don't need the new >>> argument anymore, even if we still do the super-deletion in >>> heap_delete(). Now that the speculative insertion will not be visible >>> (as in seen on a tuple they could delete) to other backends we can just >>> do the super deletion if we see that the tuple is a promise one. >> >> I disagree. I think it's appropriate that the one and only "super" >> heap_delete() caller make a point of indicating that that's what it's >> doing. The cost is only that the two other such callers must say that >> they're not doing it. Super deletion is a special thing, that logical >> decoding knows all about for example, and I think it's appropriate >> that callers ask explicitly. > > Unconvinced. Not breaking an API has its worth. The heapam API is not that stable, we've added arguments to those functions every once in a while, and I don't recall any complaints. So I'm with Peter that super-deletion should be requested explicitly by the caller. That said, I'd actually like to see a separate heap_super_delete() function for that, rather than piggybacking on heap_delete(). It's a quite different operation. There'll be some duplication, but seems better than a maze of if-else's in heap_delete. - Heikki
В списке pgsql-hackers по дате отправления: