Re: why copy tuple in the end of trigger when nothing changed in NEW OLD record variable
В списке pgsql-hackers по дате отправления:
| От | billy |
|---|---|
| Тема | Re: why copy tuple in the end of trigger when nothing changed in NEW OLD record variable |
| Дата | |
| Msg-id | 484F5B47.0460FE.04501@m12-15.163.com обсуждение исходный текст |
| Ответ на | why copy tuple in the end of trigger when nothing changed in NEW OLD record variable ("billy" <billywq@163.com>) |
| Список | pgsql-hackers |
Tom Lane,
er, your explanation is reasonable.
But at least the comment if (newtuple != tuple) /* modified by Trigger(s) */ { ..... is likely to misdirect us.
It took me a few hours to figure it out. :-(
======= 2008-06-10 23:43:00 In your letter you say:=======
>"billy" <billywq@163.com> writes:
>> I think we can add some judgment conditions in function plpgsql_exec_trigger() to avoid this problem.
>
>I don't especially see the point of adding extra complexity here.
>AFAICS you are talking about avoiding one or two palloc/pfree
>cycles, which is surely down in the noise compared to the cost of
>calling a plpgsql trigger.
>
> regards, tom lane
>
>--
>Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-hackers
billy
billywq@163.com
2008-06-11
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера