Re: Row visibility issue with consecutive triggers, one being DEFERRED
В списке pgsql-general по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Row visibility issue with consecutive triggers, one being DEFERRED |
| Дата | |
| Msg-id | 30506.1433426178@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Row visibility issue with consecutive triggers, one being DEFERRED (Marc Mamin <M.Mamin@intershop.de>) |
| Ответы |
Re: Row visibility issue with consecutive triggers, one
being DEFERRED
|
| Список | pgsql-general |
Marc Mamin <M.Mamin@intershop.de> writes:
> The test below is running fine
> but if you add the trigger push_foo_tr (uncomment)
> then the exception is raised.
Doesn't that trigger result in infinite recursion?
> CREATE OR REPLACE FUNCTION push_foo_trf () returns trigger AS $$
> BEGIN
> UPDATE foo SET (id,v) = (NEW.id,NEW.v) WHERE id=NEW.id;
> RETURN NEW;
> END; $$ language plpgsql;
> --CREATE TRIGGER push_foo_tr
> -- AFTER UPDATE ON foo
> -- FOR EACH ROW EXECUTE PROCEDURE check_foo_trf();
AFAICS, each trigger firing would re-queue another one because of
the fresh UPDATE.
regards, tom lane
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера