On Tuesday 11 August 2009 19:00:30 Tom Lane wrote: > I wrote: > > Dean Rasheed <dean.a.rash...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
