On Sun, 1 Dec 2002, Tom Lane wrote:
> Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> > On 30 Nov 2002, Neil Conway wrote:
> >> Have we decided how this would even work? Last I heard, Tom still had
> >> some major reservations about the practicality of implementing these --
> >> for example, would you re-evaluate all constraints that SELECT from a
> >> table when the table changes?
>
> > You'd have to either do it in all cases or come up with something that was
> > smart enough to limit the cases to some extent based on the expression. I
> > doubt that it'd perform terribly well, especially at first.
>
> Note that you can get the "stupid" semantics (run the subselect only
> when the constrained table changes) today: just hide the subselect in
> a user-defined function that's called from the constraint expression.
> Or put the whole check in a trigger instead of using a constraint.
>
> I don't think we should bother with direct support of subselects in
> constraints unless we can come up with an implementation that is
> significantly better than what you can accomplish with these
> workarounds.
Well, the problem is that user defined triggers trying to do the real
semantics for update/insert on the "other" tables of the constraint seem
to me like they'll have the same issues as foreign keys do currently,
either you'll be forced to write something too strong and deadlock alot,
or you'll write something too weak and end up with constraint violations
with concurrent transactions unless you basically write a very low level C
function to do it for you. I guess this, since in general, the non-action
foreign keys really are just check constraints with a subselect
effectively.