Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Дата
Msg-id CAM3SWZRmkVqmRCs34YtZPOCn+HmHqtcdEmo6==nqz1kNA43DVw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Список pgsql-hackers
On Fri, Dec 5, 2014 at 10:00 AM, Josh Berkus <josh@agliodbs.com> wrote:
> I thought the point of INSERT ... ON CONFLICT update was so that you
> didn't have to care if it was a new row or not?
>
> If you do care, it seems like it makes more sense to do your own INSERTs
> and UPDATEs, as Django currently does.
>
> I wouldn't be *opposed* to having a pseudocolumn in the RETURNed stuff
> which let me know updated|inserted|ignored, but I also don't see it as a
> feature requirement for 9.5.

Agreed. Importantly, we won't have painted ourselves into a corner
where we cannot add it later, now that RETURNING projects updates
tuples, too (V1.5 established that). I'm pretty confident that it
would be a mistake to try and make the inner "excluded" and "target"
aliases visible, in any case, because of the annoying ambiguity it
creates for the common, simple cases. I think it has to be a magic
function, or something like that.

I really hoped we'd be having a more technical, implementation level
discussion at this point. Simon rightly emphasized the importance of
getting the semantics right, and the importance of discussing that up
front, but I'm concerned;  that's almost all that has been discussed
here so far, which is surely not balanced either.

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: GSSAPI, SSPI - include_realm default
Следующее
От: Robert Haas
Дата:
Сообщение: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}