Frank van Vugt <ftm.van.vugt@foxi.nl> writes:
> The only thing I can think of is that the handling of pol X and creation of
> pol Y from within spawn_pol() is somehow messing things up, but......
Certainly the mere firing of a deferred trigger isn't the problem; we do
that all the time. What struck me about the traceback you showed is
that it involved an attempt by the planner to constant-fold an
SQL-language function that was used in the trigger function's query
(and was presumably marked IMMUTABLE and had constant arguments in the
query).
Because the trigger function is plpgsql, this could happen only the
first time the trigger is fired in a particular session (unless you are
using EXECUTE to invoke the update command?). If the problem is related
to the planner constant-folding environment, then the first-time-only
limitation would help make it hard to reproduce.
regards, tom lane