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

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