On Sun, 1 Dec 2002, Tom Lane wrote: > Stephan Szabo <[EMAIL PROTECTED]> 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. ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
