Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic) |
| Дата | |
| Msg-id | 11808.1252365005@sss.pgh.pa.us обсуждение |
| Ответ на | Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic) (Alvaro Herrera <alvherre@commandprompt.com>) |
| Ответы |
Re: manually setting the command tag (was Re: 8.4:
suppress_redundant_updates trigger vs. "Upsert" logic)
Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic) |
| Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Pavel Stehule escribi�:
>> Isn't better to solve the the correct diagnostics for INSTEAD rules or triggers?
> As far as I can tell it's not possible to do better without letting the
> user put their hands on the tag.
And how is the user going to do better? For example, what if there are
two triggers trying to set the result, perhaps because two different
commands have been generated by DO ALSO rules?
I don't think that "put it on the user's shoulders" is a good solution.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера