Re: Re: [COMMITTERS] pgsql: Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
В списке pgsql-hackers по дате отправления:
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Re: [COMMITTERS] pgsql: Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE. |
| Дата | |
| Msg-id | 555DD2A9.202@iki.fi обсуждение исходный текст |
| Ответ на | Re: Re: [COMMITTERS] pgsql: Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE. (Peter Geoghegan <pg@heroku.com>) |
| Список | pgsql-hackers |
On 05/21/2015 05:08 AM, Peter Geoghegan wrote: > On Wed, May 20, 2015 at 6:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I am not really sure that it was a good idea to invent >> this command tag. In fact, I'm pretty sure it was a *bad* idea --- >> what will happen if we ever create a statement actually named UPSERT? > > Why would we invent a statement actually named UPSERT? And if we did, surely it would do some sort of an upsert operation, we could use the UPSERT command tag for that too. That said, I'm also not sure adding the UPSERT command tag is worth the trouble. I'm OK with ripping it out. The row count returned in the command tag is handy in the simple cases, but it gets complicated as soon as you have rules or triggers, so you can't rely much on it anyway. So as long as we document what the count means for an INSERT ... ON CONFLICT, it should be OK to use the INSERT tag. - Heikki
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера