At 09:30 PM 2/5/00 +0100, Jan Wieck wrote:
>> o Under RESTRICT, by contrast, the system realizes "ahead of
>> time" that row R2 exists and will violate the constraint if
>> R1 is deleted, and so rejects the DELETE out of hand.
> That'd mean in last consequence, that RESTRICT actions aren't
> DEFERRABLE, while the rest of their constraint definition is!
That's how I read it, too. Pardon me while I run off to vomit in
the toilet.
> Anyway, cannot work with the actual implementation of the
> trigger queue, so we could either make RESTRICT and NO ACTION
> identical (except for different ERROR messages), or leave the
> SQL3 RESTRICT out of 7.0 while changing NO ACTION to fire the
> message.
> I'd prefer to have them identical in 7.0, because according
> to Date they have no semantic difference, so it'll buy us
> little if we complicate the trigger stuff more than required
> right now.
If others on the list agree, I think this is an excellent idea. I
see no semantic difference that the application will see, either,
other than a difference in execution time.
Raising the exception before the delete or update seems more an efficiency
hack than anything, i.e. it's much less expensive to short-circuit the
delete/update rather than finish it, check afterwards, and roll it
back.
- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.