Re: Inconsistent/wrong behavior of pg_trigger_depth when used with DEFERRED CONSTRAINTS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com>
Cc: pgsql-sql <pgsql-sql(at)postgresql(dot)org>
Subject: Re: Inconsistent/wrong behavior of pg_trigger_depth when used with DEFERRED CONSTRAINTS
Date: 2017-05-31 14:55:11
Message-ID: 12406.1496242511@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com> writes:
> I just run into a behavior that I consider wrong. Test case :

Hmm ... after looking at this, I'm not sure why you're surprised.
In CONSTRAINTS ALL IMMEDIATE mode, when the first invocation of
the trigger function does an UPDATE, the ensuing trigger firing
occurs at the end of the UPDATE statement. So it occurs while
the outer trigger is still active, pg_trigger_depth() returns 2,
and all is well. However, when the trigger firing is deferred,
that means it's deferred till end of transaction. So the trigger's
UPDATE merely queues a trigger firing request to be done later.
When the request is serviced, we're not inside the original trigger
anymore, so pg_trigger_depth() returns 1, and the trigger queues
another request. Lather rinse repeat.

In other words, pg_trigger_depth() tells you about the dynamic
state of the control stack; it's not a proxy for detecting whether
the action that caused the trigger firing was itself done by a
trigger. At least not when you're working with deferrable triggers.

You might have better luck by testing to see if the update you are
thinking of doing would be a no-op.

regards, tom lane

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Achilleas Mantzios 2017-06-01 08:38:47 Re: Inconsistent/wrong behavior of pg_trigger_depth when used with DEFERRED CONSTRAINTS
Previous Message tel medola 2017-05-30 23:29:34 Re: Lost my tablespace