Re: Fixing handling of constraint triggers

2010/1/17 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> I want to do something about the open item discussed in this thread:
> http://archives.postgresql.org/message-id/20090811111446.GA25965@depesz.com
>
> The right way to handle that, IMO, is to create pg_constraint rows for
> triggers created via CREATE CONSTRAINT TRIGGER.  Then,
> AfterTriggerSetState can initially search pg_constraint to identify
> which constraint is being targeted.  Aside from allowing it to throw a
> more understandable error for non-deferrable index constraints, this
> will greatly simplify its search logic, which is a mess right now.
>
> [snip]
>
> AFAICS the only user-visible change in behavior from prior versions
> will be that the system will complain if you try to create a constraint
> trigger that has the same name as an existing constraint of another type
> on the same table.  This doesn't seem like a big problem in practice,
> and in any case it's appropriate since a conflict would make it unclear
> which constraint SET CONSTRAINTS is meant to apply to.

Agreed. That's much neater. However, it does introduce a change in
behaviour - if you have 2 constraints with the same name in different
schemas, one deferrable, and one not, and the non-deferrable one is
first on the search path, then you'll get an error if you try to defer
the other one, referring to it with an unqualified name. This used to
work, when it was searching for the trigger first.

So perhaps the code should continue searching after finding a
non-deferrable constraint, remembering the fact that it found one, and
only report the error at the end if it didn't also find a deferrable
one.

Regards,
Dean