Re: misleading error message in 8.5, and bad (?) way deferred uniqueness works

I wrote:
> Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)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