On Tuesday 11 August 2009 19:00:30 Tom Lane wrote:
> I wrote:
> > Dean Rasheed <dean.a.rasheed@googlemail.com> writes:
> >> [The reason is that it actually searches for the trigger enforcing the
> >> constraint, and there isn't one if it's not deferrable. So the current
> >> code can't distinguish between a non-existent unique constraint and a
> >> non-deferrable one.]
> >
> > Yeah. Is it worth searching pg_constraint first, just so that we can
> > give a better error message?
>
> Actually, a bit more digging reminded me of why the code does it that
> way:
>
> Note: When tgconstraint is nonzero, tgisconstraint must be true,
> and tgconstrname, tgconstrrelid, tgconstrindid, tgdeferrable,
> tginitdeferred are redundant with the referenced pg_constraint
> entry. The reason we keep these fields is that we support
> "stand-alone" constraint triggers with no corresponding
> pg_constraint entry.
> I'm sure somebody would complain if we removed the user-level constraint
> trigger facility :-(.
I know of several people using them - out of the simple reason its the only
possibility to get deferred triggers atm... (Which in those cases are used to
update materialized views)
Actually I plan to check (and possibly discuss here) how complex statement
level deferred triggers would be somewhat soon...
Andres