Re: Row visibility issue with consecutive triggers, one being DEFERRED - Mailing list pgsql-general

From Tom Lane
Subject Re: Row visibility issue with consecutive triggers, one being DEFERRED
Date
Msg-id 30506.1433426178@sss.pgh.pa.us
Whole thread Raw
In response to Row visibility issue with consecutive triggers, one being DEFERRED  (Marc Mamin <M.Mamin@intershop.de>)
Responses Re: Row visibility issue with consecutive triggers, one being DEFERRED  (Marc Mamin <M.Mamin@intershop.de>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_relation_size performance issue
Next
From: Melvin Davidson
Date:
Subject: Re: pg_relation_size performance issue