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 :-(. It might be worth the trouble to change things so
that there actually is a pg_constraint entry associated with a user
constraint trigger; and then we could do the search as suggested above.
In principle we could also remove the redundant columns from pg_trigger,
but that would mean an extra catalog search each time we set up a
trigger, so I dunno if that would be a good step or not.
Anyway it's looking like a slightly nontrivial project. Maybe we should
just rephrase the error message Hubert is complaining about.
regards, tom lane