manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)
В списке pgsql-hackers по дате отправления:
| От | Alvaro Herrera |
|---|---|
| Тема | manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic) |
| Дата | |
| Msg-id | 20090907214210.GP8894@alvh.no-ip.org обсуждение |
| Ответы |
Re: manually setting the command tag (was Re: 8.4:
suppress_redundant_updates trigger vs. "Upsert" logic)
|
| Список | pgsql-hackers |
Mark Reid wrote: > It'll similarly break any code where a result of "UPDATE 0" is assumed to > indicate that the record does not exist. I wonder if this could be helped if the trigger had a way of overriding the emitted command tag. There are countless reports of trouble because somebody has an INSTEAD rule in the table, and the tag emits something that's not quite acceptable for some outer software layer. The problem is that there's no way at all to make the command tag behave! For example, we could offer a new SPI function, say SPI_settag(), which sets the command tag string. PL/pgSQL could expose this via a new command, for example COMMANDTAG. So if there's a function that is used in a INSTEAD rule for (say) an UPDATE, this function would finish with COMMANDTAG 'UPDATE num' and make the external framework happy. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера