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 по дате отправления: